职业概述

Career overview

和我那个时代的许多孩子一样，我的职业生涯始于下午送报纸（骑自行车），然后在大学期间从事建筑工作。从工程学院毕业后，我参与了阿波罗计划，为一家设备制造商设计电脑，然后在佛罗里达州坦帕市从事系统分析师的工作，同时攻读商业硕士学位。

Like many kids of my era, my career started with afternoon newspaper delivery (by bicycle) and then construction jobs during college. After graduating from engineering school, I worked on the Apollo program, designed computers for an equipment manufacturer, and then had a systems analyst job in Tampa, Florida, while pursuing a master’s degree in business.

在从事了几份工程工作后，我决定拓展管理领域，而不是深入研究工程，因此在 1970 年，我获得了坦帕南佛罗里达大学的管理学硕士学位。后来在 20 世纪 70 年代初，我获得了注册会计师 (CPA) 证书在德克萨斯州。5^当时，IT 专业人士通常向首席财务官汇报，拥有 CPA 有助于职业发展。我从未从事过公共会计工作，但获得会计技能是值得的。凭借工程背景，我可以与工程师和技术人员沟通。凭借商业和金融背景，我可以与经理和高管沟通。这种双重能力影响了我的整个职业生涯。

After several engineering jobs, I decided to broaden into management rather than dive deeper into engineering, so in 1970 I obtained a master of science in management degree from the University of South Florida in Tampa. Later in the early 1970s, I obtained a Certified Public Accountant (CPA) certificate in Texas.⁵ During this time, IT professionals typically reported to a chief financial officer and having a CPA was helpful in career advancement. I never practiced public accounting but gaining accounting skills was worthwhile. With a background in engineering, I could communicate with engineers and technologists. With a background in business and finance, I could communicate with managers and executives. This dual ability impacted my entire career.

5.当时，要获得德克萨斯州的 CPA 资格，需要在会计或工业公司有工作经验。

5. At that time, obtaining a CPA in Texas required experience with either an accounting or industrial firm.

研究生毕业后，我去了休斯顿，在埃克森美孚公司担任了六年的业务系统分析师和会计主管（参见图 1.2的职业概述）。然后去了亚特兰大，做了几份系统工作，最后在一家电力公司担任系统开发经理。这时，我的职业生涯开始朝着一个全新的方向发展，我成为了一家初创的结构化开发咨询和培训公司 Ken Orr and Associates (KOA) 的销售和营销副总裁。由于从亚特兰大到托皮卡通勤太麻烦，我离开了 KOA，开始了近 30 年的独立顾问生涯，其间做过两份短暂的全职工作。其中一次短暂的插曲是加入 Optima 的 CASE 工具领域。我从产品经理做起，然后成为咨询副总裁。

From graduate school, it was off to Houston, for six years as a business systems analyst and accounting supervisor at Exxon (see Figure 1.2 for a career braid overview). Then to Atlanta, taking a couple of systems jobs until I ended up at a power company as systems development manager. At this point my career careened off in an entirely new direction, as I became vice president of sales and marketing for a start-up, structured development consulting and training firm, Ken Orr and Associates (KOA). Leaving KOA because of the commute from Atlanta to Topeka, I began a nearly 30-year stint as an independent consultant, punctuated by two brief full-time jobs. One of these brief interludes was to jump into the CASE tools fray with Optima. I started as a product manager and then became vice president of consulting.

虽然我是一名独立顾问，但我的大部分敏捷相关工作都是在 IT 研究和咨询公司 Cutter Consortium 担任敏捷项目管理总监和研究员。在我职业生涯的最后十年，我为一家全球软件交付和 IT 咨询公司 Thoughtworks 工作。我度过了一段美好的时光。

Although an independent consultant, most of my agile-related work has been associated with the Cutter Consortium, an IT research and consulting company, as director of agile project management and fellow. In the final decade of my career, I worked for a worldwide software delivery and IT consulting firm, Thoughtworks. I had a great run.

变形记这个词源自希腊语，意为“转变”——字面意思是“形成不同的形态”。《变形记》是罗马诗人奥维德的一首诗，记述了一系列基于希腊神话的故事，其中的人物经历了个人的转变。1912 年，弗朗茨·卡夫卡写了《变形记》 《变形记》 6^是一部中篇小说，讲述了一位推销员变成一只可怕的虫子以及这种转变的后果。过去 60 年来，软件行业（事实上，整个技术领域）一直被推动变革的个人不断改变。通过提供我个人转变的见解，我希望说明推动其他人转变的因素。我们都是毛毛虫，努力变成蝴蝶。

The word metamorphosis, from the Greek, means to “transform”—literally, to “form differently.” “Metamorphoses,” a poem written by the Roman poet Ovid, chronicles a series of stories based on Greek myths in which the characters undergo personal transformations. In 1912, Franz Kafka wrote The Metamorphosis,⁶ a novella about a salesman transformed into a monstrous bug and the consequences of that conversion. The software industry—in fact, the entire technology realm—has been transformed repeatedly over the last six decades by the individuals driving change. By providing insight into my personal transformation, I hope to illustrate what drove others as well. We are all caterpillars, struggling to become butterflies.

6 . 或《转变》，取决于德语的翻译。

6. Or The Transformation, depending on the translation from German.

在思考这本书的过程中，我意识到我的动力，无论是在事业上还是在个人生活中，都是在寻求冒险。我的第一次职业冒险是参与阿波罗登月任务。我的第一次攀岩冒险是在北卡罗来纳州山区一块 25 英尺高、缓坡的花岗岩上。我的蜕变开始了。

In reflecting for this book, I realized my driver, in both career and personal life, was seeking adventure. My first career adventure was working on the Apollo moon mission. My first climbing adventure was on a 25-foot, gently sloping slab of granite in the mountains of North Carolina. My metamorphosis had begun.

软件

Software

软件的定义是什么？首先，软件就是软的，正如 20 世纪 70 年代的故事“权衡软件”所阐明的那样。人们对软件的误解一直持续到今天。你可以踢硬件。你甚至看不到软件（尽管你可以看到软件的结果）。这种混乱不仅让广大公众感到困惑；企业领导者也陷入困境，因为他们对技术总体和软件开发具体了解甚少。

What defines software? First, it is, well, soft, as illustrated by the 1970s-era story “Weighing Software.” Misunderstandings about software persist to this day. You can literally kick hardware. You can’t even see software (although you can see the results from it). This confusion has not just flummoxed the public at large; business leaders have floundered because they poorly understood technology in general and software development specifically.

我一直在寻找一种类比，帮助人们弥合这种无形差距。想象一下在书中写下文字和编写软件代码之间的类比。《指环王》三部曲包含约 575,000 个单词。如果将一本《指环王》的书凑成 200,000 个单词，假设每个单词有 3 行代码 (LOC)，^那么每本书就有 600,000 行代码。考虑到一个中等规模的软件系统有 3000 万行代码，这相当于大约 150 本书。自动驾驶汽车软件将有数亿行代码。

I’ve always looked for an analogy that would help people bridge this intangibility gap. Think of the analogy between writing the words in a book and writing software code. The Lord of the Rings trilogy contained about 575,000 words. Rounding up a single Lord of the Rings book to 200,000 words, and assuming there are 3 lines-of-code (LOC) per word,⁷ there would be 600,000 LOC per book. Considering a moderate-size software system of 30 million LOC, this translates to about 150 books. Autonomous car software will have hundreds of millions of LOC.

7 . 这是关键假设，并且高度依赖于计算机语言。每个单词 3 LOC 是一个估计，但对于本示例来说已经足够了。

7. This is the key assumption, and it is highly computer language dependent. Three LOC per word is a guesstimate, but good enough for the purposes of this example.

想象一下，你接到一个项目任务，要写一系列 150 本小说。你会如何组织员工？需要多少员工？写作时间多久？你会扮演哪些角色 — — 作家、高级作家、情节策划师、角色开发者、连贯性编辑、内容编辑、文字编辑、风格审阅者、图形设计师？你会如何为团队分配角色 / 人员？你如何在团队之间进行协调？你会使用什么样的组织结构 — — 按角色组（例如，编辑组）还是按跨职能团队（一本书所需的所有角色）？谁来做哪些决定？你的读者是想一次性读完整个系列，还是想分时间段读完一系列书籍？你将如何与潜在读者互动，以了解你的工作是否进展顺利？你需要为这 150 本书进行什么级别的规划？第一本书的当前规划级别与第 150 本书的规划级别是否不同？思考如何领导、组织和管理这个 150 本书的项目，会让你对管理大型软件开发工作的规模和复杂性有所了解。此外，所有这些问题的答案都会随着时间的推移而改变。

Imagine you were tasked with a project to write a series of 150 novels. How would you organize the staff? How many staff would you need? How long do you have? What roles would you have—writer, senior writer, plot planner, character developer, consistency editor, content editor, copyeditor, style reviewer, graphics designer? How would you assign roles/people to teams? How would you coordinate between teams? What organizational structure would you use—by role groups (an editorial group, for example), or by cross-functional teams (all required roles for a book)? Who makes which decisions? Do your readers want the entire series at one time, or a sequence of books parceled over time? How will you interact with potential readers to see if your effort is on track? What level of planning do you need for the 150 books? Is the current planning level different for book 1 than for book 150? Thinking about leading, organizing, and managing this 150-book project gives you some idea of the scale and complexity of managing a large software development effort. Furthermore, the answers to all of these questions will change over time.

软件开发

Software development

从我从事软件工作的第一天起，我就一直在思考这个问题：“你是做什么的？”如今，随着技术的普及，这个问题可能更容易回答，但我仍然觉得很尴尬。这就像人们问我做什么好玩一样。解释为什么用两根手指悬在垂直的岩壁上很有趣也是很有挑战性的。

From day one of my software career, I’ve struggled with the question, “What do you do?” Today, with the ubiquity of technology, the question may be easier to answer, but I still find it awkward. It’s similar to when people ask what I do for fun. It can also be challenging to explain why dangling off a vertical rock face by two fingers is fun.

从智能手机上的应用程序，到距离地球 100 万公里的詹姆斯·韦伯太空望远镜的运行，再到生物技术中的快速基因测序，软件运行着世界。然而，你可以拿着智能手机，可以看到韦伯的金色翅膀，你可以观察基因序列行（AGCT ⁸的组合）在显示器上滚动。但你看不到软件；它是一种抽象。

From apps on your smartphone, to the operation of the James Webb Space Telescope 1 million kilometers from Earth, to rapid gene sequencing in biotechnology, software runs the world. However, you can hold a smartphone in your hand, you can see the golden wings of the Webb, and you can observe the rows of gene sequences—combinations of AGCT⁸—scroll by on your monitor. But you can’t see software; it is an abstraction.

8.腺嘌呤（A）、鸟嘌呤（G）、胞嘧啶（C）、胸腺嘧啶（T）。

8. Adenine (A), guanine (G), cytosine (C), and thymine (T).

软件之于硬件，就如同文字之于演员。文字脚本告诉演员要说什么以及如何移动。代码脚本告诉汽车厂的计算机化机械臂将下一个零件安装到装配体上的哪个位置。你看不到是什么驱动演员移动，你只能看到动作。同样，你看不到是什么驱动机械臂，你只能看到动作。

Software is to hardware as words are to actors. A script of words tells an actor what to say and how to move about. A script of code tells a computerized robotic arm in an automobile plant where to attach the next part to an assembly. You don’t see what drives the actor to move, you just see the movement. Likewise, you don’t see what drives the robotic arm, you just see the movement.

软件指令告诉计算机要执行哪些任务。软件可分为多种类型，从操作系统（Unix、Windows、Linux）到应用程序（Google Maps、Microsoft Word）。基于计算机的硬件设计逻辑，计算机特定的机器代码将高级语言连接到硬件。从本质上讲，“门”控制着电路中的电流。它有两种状态——开和关。门由晶体管组成，通过排列 AND、OR、XOR、NOT（以及其他一些）逻辑门来改变电流，从而赋予计算机功能。机器语言（例如二进制）源自门结构。幸运的是，如今很少有开发人员需要了解机器语言，因为如今一行代码可能翻译成数百甚至数千行机器语言代码。

Software instructions tell a computer which tasks to perform. Software can be categorized into various types, from operating systems (Unix, Windows, Linux) to applications (Google Maps, Microsoft Word). Based on a computer’s hardware design logic, computer-specific machine code interfaces higher-level languages to the hardware. At the core, a “gate” controls the flow of electric current through a circuit. It has two states—on and off. The gate consists of transistors that alter the current flow by the arrangement of AND, OR, XOR, NOT (and a few others) logic gates, giving a computer its capabilities. Machine languages, such as binary, are derived from the gate structures. Luckily, few developers today need to know machine language because a line of code today might translate into hundreds or even thousands of lines of machine language code.

软件开发就是写剧本——不过是写给计算机看的，而不是给演员看的。但想想整部电影的剧本吧。电影有主题（善与恶、家庭剧、浪漫喜剧）、人物、情节、动作序列、冲突和情节转折。软件开发有预期的结果、功能要求、数据设计和用特定语言（COBOL、Java、Python）编码。制作电影是一种协作；软件开发也是如此。从本质上讲，软件开发是关于人的——他们的创造力、组织、知识、动机和技能。

Software development is script writing—but for a computer, not an actor. But think of the script for an entire movie. Movies have themes (good versus evil, family drama, romantic comedy), characters, plots, action sequences, conflicts, and plot twists. Software development has desired outcomes, the feature requirements, data design, and coding in a specific language (COBOL, Java, Python). Making a movie is a collaborative effort; so is software development. At its core, software development is about people—their creativity, organization, knowledge, motivation, and skill.

软件开发时代

Software development eras

为了整理软件开发的历史，我将这六十年划分为四个时代。虽然我根据自己的经验命名了各个时代并划定了它们的时间线，但它们反映了行业中正在发生的事情。其中两个时代进一步划分为几个时期。图 1.3显示了软件开发的时代，而图 1.4提供了具体方法和方法论的时间线。

To organize the history of software development, I divided six decades into four eras. Although I named the eras and delineated their timeline based on my experience, they mirror what was occurring in the industry. Two of the eras are further divided into periods. The eras of software development are illustrated in Figure 1.3, while Figure 1.4 provides a timeline of specific methods and methodologies.

• 狂野西部（1966–1979）

• Wild West (1966–1979)

• 结构化方法和纪念性方法论⁹（1980-1989）

  9.我首次使用“纪念碑式方法论”这一术语是在《自适应软件开发》（Highsmith，2000）一书中。

• Structured Methods and Monumental Methodologies⁹ (1980–1989)

  9. I first used the term “Monumental Methodologies” in Adaptive Software Development (Highsmith, 2000).

• 敏捷的起源（1990-2000）

  • 快速应用程序开发 (RAD)

  • 激进的应用程序开发

  • 自适应软件开发

• Roots of Agile (1990–2000)

  • Rapid Application Development (RAD)

  • RADical Application Development

  • Adaptive Software Development

• 敏捷 (2001–2021)

  • 流氓队（2001–2004）

  • 勇敢的高管（2005-2010）

  • 数字化转型（2011-2021）

• Agile (2001–2021)

  • Rogue Teams (2001–2004)

  • Courageous Executives (2005–2010)

  • Digital Transformation (2011–2021)

正如其名称所示，狂野西部时代十分狂野。软件工程¹⁰当时还处于起步阶段，人们对如何“进行”软件开发的知识微乎其微。到了 20 世纪 60 年代中后期，早期的商业应用集中在会计方面 - 总账会计、工资单、固定资产和应付账款 - 所有这些内部应用程序的价值主张都是提高生产率和降低成本。软件使企业能够更快地完成必要的事情。在这个时代，软件是一门神秘的艺术。公司雇佣“魔术师”为他们编写代码。我在这个时代最有成就感的项目是参与阿波罗登月任务 - 一次难忘的经历。在狂野西部时代，在我自己的寻找中，我在 14 年内为 7 家公司工作过，分布在从佛罗里达到明尼苏达州再到德克萨斯和佐治亚州的四个不同地方。

The Wild West era was, as the name suggests, wild. Software engineering¹⁰ was in its infancy and the knowledge of how to “do” software development negligible. By the mid-to-late 1960s, early business applications concentrated on accounting—general ledger accounting, payroll, fixed assets, and accounts payable—all internal applications whose value proposition was productivity and cost reduction. Software enabled businesses to do necessary things faster. During this era, software was an arcane art. Companies hired “magicians” to write code for them. My most rewarding project during this era was working on the Apollo moon shot mission—an unforgettable experience. In the Wild West era, in my own searching, I worked for seven companies in 14 years, spread out in four dispersed locations from Florida to Minnesota to Texas and Georgia.

10.在这个时代，人们使用了软件工程这个术语。我在前言中解释了软件开发和软件工程这两个术语的使用。

10. In this era, the term software engineering was used. My use of the terms software development and software engineering is explained in the preface.

结构化方法和纪念碑式方法论时代横跨 20 世纪 80 年代。到 20 世纪 70 年代末，结构化技术开始受到那些想要超越“编码和修复”临时开发方法的个人的欢迎。结构化方法（利用数据流图、Warnier-Orr 图、实体关系模型和结构图等技术）逐渐成为主流。所谓的瀑布生命周期与这些结构化方法相结合，形成了纪念碑式方法论，在其中添加了阶段、大量文档和流程。在这十年中，我积极参与结构化方法论的教学、咨询、学习、推广、撰写和销售。

The Structured Methods and Monumental Methodologies era spanned the 1980s. By the late 1970s, structured techniques were becoming popular with individuals who wanted to move beyond the “code and fix” ad hoc approach to development. Structured methods—utilizing techniques such as data flow diagrams, Warnier-Orr diagrams, entity-relationship models, and structure charts—edged into mainstream status. So-called waterfall life cycles were combined with these structured methods into Monumental Methodologies, adding phases, extensive documentation, and process to the mix. I was heavily involved in teaching, consulting, learning, promoting, writing about, and selling structured methods and methodologies during this decade.

在敏捷的起源时期，人们开始反抗规范方法论及其缺乏灵活性和速度。首先是快速应用程序开发 (RAD)，然后是 Scrum、极限编程、欧洲的动态系统开发方法 (DSDM) 等新事物，和自适应软件开发——敏捷革命的种子已经播下。到这个时代结束时，互联网革命要求对软件开发进行新的思考。我开始这个时代时沉浸在结构化方法中，但到最后我却 180 度大转弯，拥抱了后来成为敏捷方法的东西。

During the Roots of Agile era, rebellion against the prescriptive methodologies—and their lack of flexibility and speed—began. First with Rapid Application Development (RAD), then with newcomers like Scrum, Extreme Programming, Dynamic System Development Method (DSDM) in Europe, and Adaptive Software Development—the seeds of the agile revolution were sown. By the end of this era, the Internet revolution demanded new thinking about software development. I began this era immersed in structured methods, but by the end I had turned 180 degrees to embrace what were to become agile methods.

敏捷时代始于 2001 年，如今已繁荣发展了二十多年。那年 2 月，我和其他 16 个人在犹他州的 Snowbird 滑雪胜地讨论当时被称为“轻量级方法”的未来。正如人们所说，剩下的就是历史了。最终成果就是《敏捷软件开发宣言》，这份文件的价值观支撑了二十年的进步。

The Agile era has now prospered for more than two decades, beginning in 2001. That February, I joined 16 other individuals at the Snowbird ski resort in Utah to discuss the future of what was then referred to as “lightweight methodologies.” And the rest, as they say, is history. The outcome was the Manifesto for Agile Software Development, a document whose values underpinned two decades of advancements.

敏捷对软件及其他领域的影响。这些 [敏捷] 原则几乎渗透到了每个行业和市场。咨询公司和商学院将它们作为解决各种企业问题的良药。它们经常通过书籍、管理研讨会和在线论坛进行分析。对于创始人只想振兴软件行业的项目来说，这已经很不错了——有些人甚至不确定它能否成功。

Agile’s Impact on Software and Beyond. These [Agile] principles have penetrated virtually every industry and market. They are prescribed by consultancies and business schools as the antidote to a variety of enterprise ailments. And they are regularly dissected through books, management seminars, and online forums. Not bad for a project the founders intended only to galvanize the software sector—and some were unsure would succeed even in that.

时间似乎不断证明反对者的错误。虽然许多管理流行语很快就消亡了，但敏捷却一直经久不衰。谷歌趋势数据显示，自 2004 年以来，全球对“敏捷”和“敏捷认证”等术语的兴趣一直呈稳步上升趋势。敏捷也成为《福布斯》、《首席信息官》、《全球医疗保健》和《哈佛商业评论》等各种出版物最近文章的焦点，探讨了其在从营销到人力资源等各个职能领域的适用性。（Thoughtworks，2018 年）

Time, it seems, continues to prove the naysayers wrong. While many management buzzwords die a quick death, Agile has proved remarkably persistent. Google Trends data shows interest in terms like “Agile” and “Agile certification” has remained on a steady upward track worldwide since 2004. Agile has also been the focus of recent articles in publications as diverse as Forbes, CIO, Global Healthcare, and Harvard Business Review exploring its applicability across functions from marketing to human resources. (Thoughtworks, 2018)

六十年的变革

Six decades of change

图 1.4所示的软件开发辫子提供了 60 年来所发生的变化的示例。通过研究以下问题可以说明这些变化的总体程度：

The software development braid shown in Figure 1.4 provides examples of the changes that have occurred over six decades. The overall magnitude of these changes will be illustrated by examining the following issues:

• 人机交互——从打孔卡到虚拟现实

• Person-to-computer interaction—from punch cards to virtual reality

• 计算机性能——速度、内存容量、存储选项呈指数级增长，同时单位成本大幅下降

• Computer performance—exponentially increasing speed, memory capacity, storage options, coupled with plunging unit costs

• 组织结构——从等级制和静态到团队网络和灵活性

• Organizational structure—from hierarchical and static to team-networks and flexibility

• 软件开发生命周期——从序列阶段和文档到提供增量价值和快速学习的迭代阶段

• Software development life cycle—from serial phases and documentation to iterative phases of delivering incremental value and rapid learning

本章描述了这些趋势，并将在以后的时代重新审视。

These trends are described in this chapter and will be reexamined in later eras.

20 世纪 60 年代末，在明尼苏达州圣保罗，我开始涉足投资——当时科技股正在上涨——并一度考虑成为一名股票经纪人。从那时起直到 20 世纪 90 年代中期，我会打电话给经纪人，根据我对已发布的“纸质”信息的分析下达口头订单。然后，经纪人使用打孔卡输入表或基于字符的终端（取决于那个年代）下订单，通过座机告诉我结果，并通过普通邮件发送纸质确认书。20 世纪 90 年代中期，嘉信理财等互联网经纪公司创造了一种不同的模式。经纪人不需要输入订单，而是由我输入。股票和市场信息现在可以即时在线获取。

IN SAINT PAUL, MINNESOTA, in the late 1960s, I dipped into investing—tech stocks were on the move—and briefly considered becoming a stockbroker. From then until the mid-1990s, I would call a broker and place a verbal order, based on my analysis of published “paper” information. Then the broker placed the order using punch card input sheets or a character-based terminal (depending on the decade), called me on a landline phone with the results, and snail mailed a paper confirmation. In the mid-1990s, Internet brokerages like Schwab created a different model. The broker didn’t enter the order; I did. Stock and market information was now instantaneously available online.

图 1.5和1.6展示了 60 年来人机界面的演变。第一张图展示了 20 世纪 60 年代的版本：打孔卡输入，打印结果为 144 个字符。哦，还有一台巨大的计算机，输入和输出之间有磁带驱动器存储。输入到输出的速度以小时为单位，其中很多都是小时。

Figures 1.5 and 1.6 illustrate the evolution of human–computer interfaces over six decades. The first figure shows the 1960s version: punch cards input, 144-character printed results. Oh, and a big honking computer with tape-drive storage in between input and output. Input to output speed was measured in hours, many of them.

快进六十年，我们来到图 1.6。一个家庭客厅里有连接到互联网的笔记本电脑、电视上播放的 Netflix 电影、平板电脑、游戏控制器、虚拟现实耳机和控制器、Wi-Fi 和数字机器猫——所有这些都可以即时使用。处理和数据存储不是在墙后面的大型计算机中进行，而是在云中进行，在网络空间的某个地方漂浮。计算机技术日益个性化和连通性对软件开发的发展产生了重大影响。

Fast forward six decades to Figure 1.6. A family living room contains laptop computers connected to the Internet, Netflix movies streaming on their TV, a tablet PC, a game controller, a virtual reality headset and controllers, Wi-Fi, and a digital robot cat—all available instantly. Rather than a big computer behind a wall, processing and data storage take place in the cloud, floating around in cyberspace somewhere. This increasing personalization and connectivity of computer technology has had a major influence on software development’s evolution.

计算机硬件技术和软件进步相互促进。要了解软件方法的演变，我们必须了解每个时代的技术，如表 1.1所示。计算性能呈指数级增长。例如，从狂野西部到敏捷时代的处理速度从 1 兆赫飙升至 5 千兆赫。处理器速度、存储和连接性等每个领域的性能提升使得人与计算机之间的连接得到了扩展，这是该领域的早期先驱者无法想象的。

COMPUTER HARDWARE TECHNOLOGY and software advances drive each other. To understand the evolution of software methods, we have to understand the technology of each era, as shown in Table 1.1. Computing performance has increased at an exponential rate. For example, processing speed from the Wild West to Agile eras ballooned from 1 megahertz to 5 gigahertz. The increased performance in each of these areas—processor speed, storage, and connectivity—has enabled an expansion of person-to-computer connectivity unimaginable to early pioneers in the field.

在 20 世纪 60 年代和 70 年代，计算机被安置在大型专用房间内，与人的互动非常冷淡。如今，个人可以在个人设备上访问数千个应用程序。软件开发深受个性化和客户关注技术的影响。表 1.1显示了计算技术的性能多年来如何呈爆炸式增长（附录中有一个包含参考资料的综合表格）。

In the early days, in the 1960s and 1970s, computers were housed in big, specialized rooms, and their interaction with people was impersonal. Today, individuals have access to thousands of applications on their personal devices. Software development has been profoundly impacted by the technologies of personal touch and customer focus. Table 1.1 shows how computing technology performance has exploded over the years (a comprehensive table including references appears in the Appendix).

极其昂贵的计算性能导致我们优化机器性能而非人员性能。到了敏捷时代，情况发生了逆转：现在，知识和创新，而不是比特和字节，推动着业务绩效。

Extremely costly computing performance led us to optimize machine performance over people performance. By the Agile era, this was reversed: Now knowledge and innovation, not bits and bytes, drove business performance.

随着我们经历这四个时代，我们将看到技术的进步如何影响软件开发，进而影响人们对计算机技术的体验。我们还将看到软件开发方法和方法论的发展，以解决当今的业务问题。

As we journey through the four eras, we will see how strides in technology impacted software development and, in turn, people’s experience with computer technology. We will also see that software development methods and methodologies evolved to solve the business problem of the day.

在组织结构和软件开发生命周期的演变中可以看到另外两个变化指标。

TWO ADDITIONAL INDICATORS OF CHANGE can be seen in the evolution of both organizational structure and software development life cycles.

首先看一下图 1.7顶部的传统组织结构图。它强调功能性、可预测性、精确性和层次性。然后检查 Jurgen Appelo 的 unFIX 组织模型的底部图表。11^它像乐高积木一样，以团队（一种团队）为导向，灵活且网络化——这正是 2020 年代成功的秘诀。同样，第 19 页的图 1.8强调了线性、有限反馈、规范瀑布生命周期与我的自适应生命周期的迭代、独特的学习循环和产品愿景之间的差异。这些鲜明的对比表明了六十年的转变。

First look at the traditional organizational diagram at the top of Figure 1.7. It screams functional, predictable, precise, and hierarchical. Then examine the bottom diagram of Jurgen Appelo’s unFIX organizational model.¹¹ It’s Lego-like, crew (a type of team) oriented, flexible, and networked—just the ticket for success in the 2020s. Similarly, Figure 1.8 on page 19 shouts out the differences between the linear, limited feedback, prescriptive waterfall life cycle, and my adaptive life cycle’s iterations, distinct learning loops, and product vision. These stark contrasts are indicative of six decades of transformation.

11.第 8 章将详细介绍 unFIX 模型。

11. More about the unFIX model in Chapter 8.

观察结果

Observations

当我为写这本书而深入记忆时，我意识到我的工作和娱乐中都贯穿着一个共同点：我本质上是一个喜欢冒险的人。我做出了冒险的职业转变，从在大公司工作的安全到在初创公司工作的动荡。我爬山、参加百英里自行车赛、参加帆船比赛、参加黑钻石滑雪道。推广 RAD 和敏捷运动等新概念同样危险。

As I dug into my memory bank for this book, I realized a common thread ran through both my work and my play: I was fundamentally an adventurous person. I made adventurous career pivots, from the safety of working for big companies to the turmoil of working for start-ups. I climbed mountains, cycled century races, raced sailboats, and skied black diamond runs. Pushing new concepts such as RAD and the agile movement was equally risky.

风险和不墨守成规相互激发能量，大多数冒险家都是不墨守成规者。作为一个好奇的人，每次我开车在山里，甚至在登山生涯结束后的今天，我都会抬头仰望，计划着我应该尝试哪条路线。但我也是一个不墨守成规者——不是为了与众不同而与众不同，而是为了即使在常规之外也对自己保持真实。我喜欢打破常规，尝试意想不到的事情。我曾经在一个朋友的研讨会上担任代课老师。课堂上讨论的是协作团队，但在工作中，如果一个团队的某个人想和另一个团队的某个人交谈，他们必须先与各自的主管交谈。当男人们去洗手间或吃午饭时，他们必须穿夹克。为什么他们有着坚定的墨守成规的文化，却对我教授的 RAD 和协作方法感兴趣，这将永远是一个谜——我无法很快摆脱这个问题。杰里·温伯格（Jerry Weinberg），您将在本书后面看到他，他对任何情况都有过这样一句话，包括对不墨守成规的情况：“当时在 IBM，留胡子而不被解雇是技术天才无可争辩的标志”（Weinberg，1985 年）。

Risk and nonconformity energize each other, and most adventurers are nonconformists. As a curious person, every time I drive in the mountains, even today when my climbing days are over, I look up and plot which route up I might try. But I’m also a nonconformist—not in the sense of being different just to be different, but in the sense of being authentic to myself even when outside the norm. I like to shake things up and try the unexpected. I once acted as substitute teacher at a workshop for a friend. The class talked about collaborative teams, but at work if someone on one team wanted to talk with someone on another team, they had to talk with their respective supervisors first. When the men went to the restroom or lunch, they had to wear jackets. Why, with their staunchly conformist culture, they were interested in RAD and collaboration methods I taught will forever be a mystery—I couldn’t get away from there fast enough. Jerry Weinberg, whom you will meet later in this book, had a quote for any situation, including one for nonconformity: “Within IBM at that time, growing a beard without getting fired was an indisputable mark of technical genius” (Weinberg, 1985) .

勇于冒险。不墨守成规。适应性强。这些行动构成了每个软件开发时代需要进一步探索的核心信息。

Adventurous. Nonconformist. Adaptable. These actions form the core message to explore further during each software development era.

阿波罗

Apollo

我的第一项任务是查看工程图纸并计算组件和系统的平均故障时间 (MTTF) 和平均修复时间 (MTTR)。有一次，我飞往大西洋中部阿森松岛的主要导弹跟踪站，监督计算机内存升级和测试。我对这次旅行印象最深刻的是乘坐空军 C-130 的不适、飞行途中发动机故障、在安提瓜过夜，以及在阿森松岛军官俱乐部的欢乐时光，当时饮料只需 10 美分。

My first assignment was looking over engineering drawings and calculating component and system mean-time-to-failure (MTTF) and mean-time-to-repair (MTTR). One time, I flew to the primary downrange missile tracking station on Ascension Island in the middle of the Atlantic Ocean to oversee a computer memory upgrade and test. What I remember most about the trip was the discomfort of flying in an Air Force C-130, losing an engine in-flight, overnighting in Antigua, and the happy hour at the officer’s club on Ascension when drinks were 10 cents.

20 世纪 60 年代初，阿波罗计划还在设计中，当时全球通信还不太稳定，因此五艘飞船配备了雷达、遥测、惯性导航系统，以及一个功能齐全但规模较小的任务控制中心，与休斯顿的那个类似。这些飞船将被部署到太平洋，以便在指令舱返回地球时对其进行获取和跟踪。我曾在其中两艘飞船上工作过，如图2.1所示。

In the early 1960s when Apollo was being designed, global communications was iffy, so five ships were retrofitted with radars, telemetry, inertial navigation systems, and a fully functioning, but smaller, mission control center mirroring the one in Houston. These ships were to be deployed to the Pacific Ocean to acquire and track the command module as it returned to Earth. I worked on two of these ships, like the one shown in Figure 2.1.

1.照片由 CPC Collection/Alamy Stock Photo 提供

1. Photo courtesy of CPC Collection/Alamy Stock Photo

“工作”这个词对于我的工作来说有点不太恰当。实际上，我审查并批准了其他人的工作。阿波罗任务涉及的实体数量令我这样的新手感到震惊。正如你所预料的那样，飞船本身有多个承包商，从锚链到计算机，应有尽有。我没有想到的是合同管理舰队——NASA、负责建造东西的 NASA 总承包商、负责监督主要承包商的其他承包商，以及空军，他们也都是同样的人。泛美航空是其中的一员。例如，对于计算机测试，可能会有一名承包商负责运行测试，还有几名观察员，每个观察员都会向其所属的上级提交测试成功或失败的报告。

“Work” was somewhat of a misnomer for my job. In reality, I reviewed and approved others’ work. The number of entities involved in the Apollo mission was startling to a newbie like me. As you would expect, there were multiple contractors for the ships themselves, for everything from anchor chains to computers. What I did not expect was the contract management flotilla—NASA, NASA prime contractors building things, other contractors to monitor the primary contractors, and the Air Force, with the same menagerie of which Pan Am was a part. For a computer test, for example, there might be a contractor running the test and several observers, each of whom supplied their own hierarchy with reports about the success or failure of the test.

帕特里克空军基地 (AFB) 位于可可比奇附近，是水星和双子座任务（以及泰坦等军用飞行器）的主要发射场，而阿波罗发射场正在帕特里克空军基地以北的梅里特岛建造。我的办公室在帕特里克。一天早上，我和朋友走进办公室，看到游客们站在大楼前真人大小的导弹展示区（图 2.2）。我们的着装很符合当时的风格，白衬衫、细细的深色领带，口袋套里塞满了笔——这是工程师的标志。我们走到其中一枚导弹前，严肃地上下打量着，然后开始大喊“十、九、八、……”，同时朝另一个方向跑去。哇，游客们都跑走了！我们一路笑着进了办公室。

Patrick Air Force Base (AFB), near Cocoa Beach, was the primary launch site for the Mercury and Gemini missions (and military vehicles like Titan), while the launch complex for Apollo was being constructed on Merritt Island, north of Patrick AFB. My office was located at Patrick. One morning, as a friend and I walked into work, we saw tourists standing around the life-sized missile display in front of the building (Figure 2.2). We were dressed for the times in white shirts, thin dark ties, and—the sure sign of an engineer—pocket protectors jammed with pens. We walked over to one of the missiles, looking seriously up and down and around, and started yelling, “Ten, nine, eight, ….” as we ran in the other direction. Wow, the tourists took off! We laughed all the way into the office.

2 . https://afspacemuseum.org/sites/patrick-air-force-base-florida/

2. https://afspacemuseum.org/sites/patrick-air-force-base-florida/

我到达时，水星计划已经完成，双子座计划正在实施，阿波罗计划正准备进行土星火箭的早期试射。我的隔壁邻居是一名空军摄像师，他邀请我陪他一起近距离观看发射——近得几乎让人头皮发麻。我们距离新闻媒体摄像机约一英里。我登上发射台上的土星火箭顶部，看到了阿波罗指挥舱内部（但不幸的是没有进去）。在土星火箭的第一次试飞中（在帕特里克基地），地面剧烈震动，导致主计算机设施的三个独立电源关闭——在飞行的前 2 到 3 分钟内，它们都处于关闭状态。

By the time I arrived, the Mercury program was completed, Gemini was under way, and Apollo was getting ready for early test launches of the Saturn rocket. My next-door neighbor was an Air Force camera operator, and he invited me to accompany him to watch launches from extremely close up—almost hair-scorchingly close. We were about a mile in front of the news media cameras. I made it to the top of a Saturn rocket on the launch pad and got to look inside the Apollo command module (but unfortunately did not go in). During the first Saturn test flight (at the Patrick site), the ground shook so violently that three separate power feeds to the primary computer facility shut down—they were down for the first 2 to 3 minutes of the flight.

舰船配备了 C 波段和 S 波段雷达、用于数据下载的遥测技术和惯性导航（当时属于机密，用于核潜艇，早于全球定位系统 [GPS]）。计算机是海军舰艇上使用的小型加固军用计算机。它有一个红色的“战斗”按钮，因此在战斗过程中，它可以超过温度限制（并真正烧毁）。这台 8 位机器的字长为 32 位，内存高达 36K（当时最大内存为 36K）。在海上，我们的编程界面是穿孔纸带（在陆地上，则是穿孔卡）。有一个控制面板，横跨 3 或 4 列，向下约 10 到 12 行——每个交叉点都是一个按钮，用于发出信号，指示当前不需要的程序从内存中退出，以便可以读入其他程序。

The ships had C-band and S-band radar, telemetry for data downloads, and inertial navigation (secret at the time, used on nuclear subs, and predating the Global Positioning System [GPS]). The computer was a reduced-size, hardened military computer used on Navy ships. It had a red “battle” button so it could run past its temperature limits (and literally burn up) while a battle was under way. This 8-bit machine had a 32-bit word length and an eye-popping 36K of memory (36K was the maximum at the time). At sea, our programming interface was punched paper tape (on land, punch cards). There was a control panel with 3 or 4 columns across and about 10 to 12 rows down—each intersection was a button that signaled currently unneeded programs to roll out of memory so others could be read in.

考虑尝试编写复杂的轨道力学计算程序，以便在内存和处理速度受限的情况下获取一个微小的指令舱，因为它出现在遥远的地平线上。除了雷达和导航数据外，另一个计算输入是飞船弯曲数据。3^指令舱获取计算非常敏感，需要在计算中使用飞船弯曲数据——所有这些都用 36K 编程。

Consider trying to program complex orbital mechanics calculations to acquire a tiny command module as it came up over the distant horizon given the memory and processing speed constraints. Besides radar and navigation data, another calculation input was ship flex data.³ The command module acquisition calculation was so sensitive it required ship flexure data in the calculation—all programmed in 36K.

3.通过在雷达之间的狭窄隧道中进行测量获得，激光通过该隧道发射以测量船舶的弯曲程度。

3. Obtained by measurements in a narrow tunnel between the radars through which a laser was beamed to measure the ship’s flex.

六个月来，我在新奥尔良的一家造船厂临时值班，那里正在建造两艘船。我们进行了海上试验——顺着密西西比河一直到墨西哥湾，试图通过寻找飞机来测试系统。在实际任务中，指挥舱将以每小时 24,000 英里的速度进入大气层，然后使用反向燃烧发动机将速度减慢到每小时 350 英里以下。我们的目标飞机以每小时数百英里的速度从船的上空飞过。前几次测试我们甚至找不到飞机。

For six months, I was on temporary duty at a shipyard in New Orleans, where two ships were being built. We went out on sea trials—down the Mississippi River to the Gulf of Mexico to test the systems by trying to find airplanes. In an actual mission, the command module would enter the atmosphere at 24,000 miles per hour, then slow down by using retro-burn engines to less than 350 miles per hour. Our target planes flew right over the ship at several hundred miles per hour. The first few tests we couldn’t even find the planes.

整个阿波罗计划规模庞大，它的成功证明了远大的愿景、创造力、协作、从失败中学习、工程专业知识和管理才能。那是一段有趣但忙碌的时光，而且能为这次活动贡献哪怕是很小的一部分，对我来说都是很棒的。回想起来，这是开启我职业生涯的一种令人兴奋的方式。然而，到第一次载人阿波罗飞行时，由于通信技术的进步，飞船已被重新利用。

The entire Apollo program was huge, and its success was a testament to a big vision, creativity, collaboration, learning through failure, engineering expertise, and management talent. It was a fun, but busy time, and it was great for me to play even a small part in this event. Looking back, it was an exciting way to begin my career adventure. However, by the first manned Apollo flight, the ships had been repurposed due to advances in communications.

在继续我的职业生涯、几个前沿项目、软件方法的状态以及为整个六十年建立管理环境之前，我首先需要为这个狂野西部时代设定技术舞台。

BEFORE CONTINUING WITH MY CAREER stops, a couple of leading-edge projects, the state of software methods, and establishing a management context for the entire six decades, I first need to set the technology stage for this Wild West era.

科技与世界

Technology and the world

阿波罗是狂野西部时代早期更广阔世界的一角，其中包括披头士乐队、越南战争、花童、反战抗议、理查德·尼克松总统和水门事件以及不断上升的通货膨胀。尽管全球地缘政治和社会发生了重大变化，但商界领袖仍一如既往。1973-1974 年和 1979 年的石油危机打击了经济，其主要影响包括工资和价格快速上涨，从而减缓了企业增长。这些条件的结合催生了滞胀一词。零售额下降，企业利润率受到影响。

Apollo was an electric piece of the wider world during the early part of the Wild West era, which included events like the Beatles, the Vietnam War, flower children, antiwar protests, President Richard Nixon and Watergate, and rising inflation. While the global geopolitical and social changes were significant, business leaders continued much as before. The economy was hit by oil crises in 1973–1974 and 1979, whose major impacts included rapid wage and price inflation, which slowed business growth. The combination of these conditions inspired the term stagflation. Retail sales sank, and corporate profit margins suffered.

一些大企业遭受了损失。特别是通用汽车和福特等制造业巨头，被欧洲和日本汽车制造商抢占了市场，这些汽车的里程数更高，成本更低。但还有另一种趋势正在出现。苹果（1976 年）、星巴克（1971 年）、微软（1975 年）和耐克（1964 年）等新兴公司表明，规模较小、行动敏捷的公司可能会有未来。

Some big businesses suffered. In particular, manufacturing titans like General Motors and Ford lost ground to European and Japanese car makers, whose vehicles offered both higher mileage ratings and lower costs. But there was another emerging trend. New companies like Apple (1976), Starbucks (1971), Microsoft (1975), and Nike (1964) showed smaller, nimble companies might have a future.

20 世纪 50 年代为企业 50 年的短视奠定了基础。经济蓬勃发展，人们有了工作，繁荣似乎是不可避免的，未来似乎可以延伸为一项宏伟的事业（当然，除非你是女性、BIPOC [黑人、土著和有色人种]、LBGTQ+ 或残疾人）。企业高管规划未来时，好像发展是可预测和线性的。然而，有些事情确实发生了变化，所以企业必须适应，但在可接受的范围内。这种可预测性的假设贯穿了从业务规划到项目管理的一切。“规划工作，按计划工作”是企业的口头禅。这种可预测性和内部关注导致了以下趋势：目标管理 (MBO) 以及成本和进度作为项目管理的主要目标。即使到了 20 世纪 80 年代中期，大公司仍然设有大型规划部门。

The 1950s had laid the groundwork for 50 years of corporate myopia. The economy boomed, people had jobs, prosperity seemed inevitable, and the future appeared to stretch out into a grand undertaking (unless, of course, you were female, BIPOC [Black, Indigenous, and people of color], LBGTQ+, or a person with a disability). Corporate executives planned for the future as if the progression was predictable and linear. Some things did change, however, so businesses had to adapt, but within acceptable limits. This assumption of predictability infused everything from business planning to project management. “Plan the work and Work the plan” was the corporate mantra. This predictability and internal focus led to trends like management by objectives (MBO) and cost and schedule as the primary objectives of project management. Even into the mid-1980s, big corporations had large planning departments.

在 20 世纪 60 年代末和整个 70 年代，IBM 主导着大型商用计算机市场。在此之前，IBM 根据客户需要的处理能力提供不同的计算机产品线。不幸的是，这些计算机（如 1620 和 7064）不兼容，因此从一种尺寸升级到另一种尺寸既困难又昂贵。IBM 360/30 于 1964 年发布，是 360 系列计算机中第一款采用通用操作系统的计算机，它拥有众多创新。磁带驱动器为这些早期系统提供了外部存储。

In the late 1960s and all of the 1970s, IBM dominated the mainframe business computer market. Prior to that time, IBM offered different lines of computers depending on how much processing power a customer required. Unfortunately, these computers, which had designations like 1620 and 7064, were incompatible, so upgrading from one size to the next was difficult and expensive. The IBM 360/30, released in 1964, was the first of the 360 series of computers having, among many innovations, a common operating system. Magnetic tape drives provided external storage for these early systems.

从 20 世纪 70 年代开始，IBM 开始在其 360 台计算机中配备随机存取磁盘驱动器。一套小型配置包含 2314 个磁盘驱动器，存储容量为 146 MB，售价为 175,000 美元⁴（如今，这种存储容量的价格约为 ½ 美分，未考虑通货膨胀因素）。随着磁盘驱动器的发展，IBM 推出了一种早期的数据库管理系统，称为信息管理系统 (IMS)。随机存取驱动器和 IMS 为软件开发带来了新的复杂性和新机遇。

Beginning in the 1970s, IBM began delivering random-access disk drives with its 360 computers. A small configuration of 2314 disk drives, with 146 MB of storage, sold for $175,000⁴ (today that much storage would cost about ½ cent, not adjusting for inflation). Commensurate with the development of disk drives, IBM introduced an early database management system, called Information Management System (IMS). Random-access drives and IMS introduced new complexity, and new opportunities, into software development.

4. 1970 年 2314 驱动器的性能和成本，IBM 档案，www.ibm.com/ ibm/history/exhibits/storage/storage_2314.html 。

4. 2314 drive performance and cost in 1970, IBM Archives, www.ibm.com/ibm/history/exhibits/storage/storage_2314.html.

小型计算机的崛起始于 20 世纪 70 年代，并延续到 20 世纪 80 年代，由数字设备公司 (DEC) 引领，该公司在 20 世纪 60 年代末发布了 PDP-8。DEC 开发了功能更强大的小型计算机，促使另一家主要制造商 Data General 在 1980 年发布了其 Eclipse 超级小型计算机。普利策奖获奖书籍 Tracy Kidder 的《新机器的灵魂》（1981 年）记录了 Eclipse 的密集开发工作。尽管如此，IBM 大型计算机在整个时代都占据了商业计算的主导地位。

The rise to prominence of minicomputers began in the 1970s and extended into the 1980s, led by Digital Equipment Corporation (DEC), which released the PDP-8 in the late 1960s. DEC developed ever more powerful minis, driving Data General, another major manufacturer, to release its Eclipse superminicomputer in 1980. The intense development effort of the Eclipse was documented in a Pulitzer Prize–winning book, Tracy Kidder’s The Soul of a New Machine (1981). Still, IBM mainframe computers dominated business computing during this entire era.

当时，人们与计算机的互动非常原始和冷漠（如图 1.5所示）。大型主机放置在专门建造的房间内，房间内有架空的地板、架空的电线箱和空调。5^计算机操作员输入卡片组、安装和拆卸磁带和磁盘驱动器，并收集和分发打印输出。由于磁盘存储非常昂贵，大多数系统都使用多种存储形式——磁带用于存储大量数据，磁盘用于存储少量数据。小型计算机系统上提供在线分时系统使用 Unix 和一些大型机，但主要用于学术和工程应用。

Interactions with computers during this time were primitive and impersonal (as illustrated in Figure 1.5). Large mainframe computers resided in specially constructed rooms with raised floors, overhead wire bins, and serious air conditioning.⁵ Computer operators input card decks, mounted and dismounted tape and disk drives, and gathered and distributed printouts. Because disk storage was so expensive, most systems used a combination of storage forms—magnetic tape for high-volume data, disks for lower-volume data. Online, time-sharing systems were available on minicomputer systems using Unix and some mainframes, but were primarily reserved for academic and engineering applications.

5.当时没有人担心能源成本或环境影响。

5. No one worried about energy costs or environmental impacts in those days.

企业高管对软件了解甚少。他们可以看到庞大的计算机，但软件却被隐藏起来。此外，当时供应商提供的大部分软件都包含在硬件价格中——软件似乎是免费的！

Software was poorly understood by business executives. They could see the mammoth computers, but the software was hidden. In addition, most of the vendor-supplied software during this time was included in the price of the hardware—software appeared to be free!

因为想从事设计和建设工作，而不是审计工作，我辞去了泛美航空的工作，搬到了明尼苏达州圣保罗，为 Univac 联邦系统部门工作，该部门为海军和阿波罗飞船制造计算机。我参与了计算机门和寄存器的设计以及早期通信调制解调器的设计。在做了两份工程工作后，我开始认为自己更像是一个通才而不是专家，并决定攻读 MBA 学位，在明尼苏达大学夜校学习必备的会计和经济学课程。我曾预料到明尼苏达州的天气很冷，但一天早上，在刮掉车窗上的冰后，在零下 78 度的寒风中开车上班，这实在太冷了。在忍受了一个冬天的寒冷后，我决定赶紧离开那里。

WANTING TO DESIGN and build rather than audit, I quit Pan Am and relocated to Saint Paul, Minnesota, to work for Univac Federal Systems Division, which manufactured computers for the Navy and Apollo ships. I was involved in designing gates and registers for computers and early communication modem design. After two engineering jobs, I began to see myself as more a generalist than a specialist and decided to pursue an MBA degree, attending night school at the University of Minnesota for the prerequisite accounting and economics courses. I had anticipated the cold weather in Minnesota but driving to work one morning, after hacking ice off the car windows, with a windchill of minus 78 degrees proved too much. Having braved the cold for one winter, I decided to high-tail it out of there.

回到南方的坦帕，我于 1970 年毕业于南佛罗里达大学，获得管理学硕士学位。作为我的硕士项目，我开发了一个模拟应用程序，用于分析从坦帕到密西西比河沿岸港口的驳船交通。当我在当地一家公司实习时，这个模型被证明很有用，管理人员对结果很满意。模拟使用了一个称为通用模拟系统 (GPSS) 的软件包。这个软件很新，所以我的教授都帮不上忙。我从不完整的手册和反复试验中了解了它的工作原理。由于当时还是打卡和打印输出的时代，周转速度很慢，我花了很多个晚上待在学校的计算机中心。然而，我的分析有一个缺陷，一位经理在我的期末演讲中指出了这一点。其中一个数据表包含错误数据，对最终结果产生了一些影响。错误数据已经给了我，但我应该更认真地检查它。在后续的项目中，我确保团队中的某个人像我一样注重细节——我努力确保团队拥有完成工作和优化团队绩效所需的多样化技能。

Back to the warmth of the South in Tampa, I graduated with a master of science in management degree from the University of South Florida in 1970. For my master’s project, I developed a simulation application for analyzing barge traffic from Tampa to ports along the Mississippi River. While I was working as an intern for a local company, the model proved useful, and managers were pleased with the results. The simulation utilized a package called the General-Purpose Simulation System (GPSS). This software was new, so none of my professors could help. I learned how it worked from incomplete manuals and trial and error. Since this was still the punch card and printout era, with slow turnarounds, I spent many evenings in the school computer center. However, there was a flaw in my analysis, which one of the managers caught in my final presentation. One of the data tables contained bad data, throwing off the final results a bit. The bad data was given to me, but I should have been more diligent in reviewing it. In projects to follow, I made sure someone on the team was as detail oriented as I was big picture oriented—I sought to ensure the team had the diversity of skills required to do the work and optimize team performance.

埃索商业系统

Esso Business Systems

1970 年，刚从商学院毕业的我搬到了德克萨斯州贝敦，就在休斯顿以东，在 Esso ⁶炼油厂担任业务系统分析师。但这份工作不仅仅是分析：它还包括设计、编程、测试、文档编制，以及在关键时刻担任大型计算机操作员。

In 1970, fresh out of graduate business school, I moved to Baytown, Texas, just east of Houston, to work in the Esso⁶ refinery as a business systems analyst. But the job wasn’t just analysis: It also included design, programming, testing, documentation, and—at crunch times—mainframe computer operator.

6.我在埃索公司工作期间，该公司更名为埃克森美孚公司。

6. Esso became Exxon while I worked there.

我参与的一个前沿项目，后来被称为管理信息系统 (MIS)。一个由年轻、热情洋溢、大多是 MBA 类型的人组成的研究小组进行了分析工作，以确定管理层的需求。当时的同事约翰·法尔伯格 (John Fahlberg) ⁷是团队中的一员，他在 2022 年的一次电话会议上提醒了我一些细节。约翰的第一个记忆是我们经常在周五晚上到当时新开的 Galleria 酒店顶楼的酒吧聚会，当然，我们在那里对长时间的工作和管理表示同情。当我们的报告被提交和批准时，我是一个编写软件系统的团队，该系统由 COBOL ⁸和 Mark IV（一种高级报告语言）代码组成，可从各种操作系统中提取数据并生成新报告。这个系统是一个大杂烩，但它有效，高管们从数据中受益匪浅。这些信息包括生产的炼油产品桶数、员工水平、维护活动、成本和其他财务分析。这是第一次，至少在贝敦地区，从多个操作系统中提取数据并进行整合以供管理。以前，管理人员从操作系统接收交易数据，但没有以整合的方式接收跨系统数据。

One leading-edge project I worked on would in the future be called a management information system (MIS). A study team consisting of young gung-ho, mostly MBA types did the analytical work to identify management’s needs. John Fahlberg,⁷ a colleague from that period, was on the team and reminded me of details in a 2022 call. John’s first recollection was our regular Friday night retreat to the top-floor bar in the then-new Galleria Hotel, where we commiserated about long work hours and management, of course. When our report was presented and approved, I was a team of one who wrote the software system, which consisted of COBOL⁸ and Mark IV (a high-level reporting language) code that extracted data from various operational systems and generated the new reports. The system was a big kluge, but it worked, and the executives benefited from the data. The information included barrels of refinery products produced, staff levels, maintenance activities, costs, and other financial analyses. It was the first time, at least in the Baytown location, data was extracted from multiple operating systems and consolidated for management. Previously, managers received transaction data from operating systems, but no cross-system data in a consolidated manner.

7.约翰后来担任塔吉特（Target）的首席财务官以及多家硅谷初创公司的首席执行官。

7. John went on to become the CFO at Target and CEO of several Silicon Valley start-ups.

那时我还是个编程新手，没有接受过正式培训，我敢肯定我的 COBOL 程序维护起来非常困难。我们确实有一些类似模式的模型，例如用交易文件更新主文件——所有这些都包含存储在磁带上的串行数据。在那个时代，文件中的最后一条记录必须包含所有 9 作为文件结束指示符。9^当时唯一的交互工具是打卡输入和打印报告。运行和测试程序的周转时间通常是一夜之间。通常需要经过几次迭代才能获得干净的编译，耗时 12 小时每次尝试。除了程序之外，将一系列程序与所需的数据文件和磁带驱动器链接在一起还需要了解 IBM 神秘的作业控制语言 (JCL)。

I was still new to programming, with no formal training, and I’m sure my COBOL programs were a maintenance nightmare. We did have a few pattern-like models, such as updating a primary file with transaction files—all of which contained serial data stored on magnetic tape. This was an era in which the last record in files had to contain all 9s as an end-of-file indicator.⁹ The only interaction tools at the time were punch card input and printed reports. Turnaround for running and testing programs was usually overnight. It often took several iterations to get a clean compile, at 12 hours per try. In addition to programs, linking a series of programs together with needed data files and tape drives required knowing IBM’s arcane Job Control Language (JCL).

8. COBOL：通用商业导向语言。

8. COBOL: Common Business-Oriented Language.

9。如果没有 9s 记录，文件读取处理在尝试读取最后一条记录之后时将中止。

9. Without the 9s record, file read processing would abort when it tried to read past the last record.

那时的测试就像一场旅行。当时没有测试工具。一旦你有了干净的编译，就开发测试数据并将其输入到卡片中，修改 JCL，然后运行测试。当然，如果文件超过 80 个字符，首先你要运行一个程序将多张卡片组合成一个扩展文件格式。毫不奇怪，许多交易文件的长度都是 80 个字符。如果你很幸运，测试结果就会被打印出来并进行分析。如果你不走运——一开始大多数时候都是这样——执行就会终止，导致核心转储。这个每行 144 个字符的整个计算机内存以十六进制¹⁰打印出来，看起来像“01 A9 34 5A D2 88 88”，一页又一页。找出你的程序从哪里开始，然后追踪执行路径，这真是太有趣了！

Testing in those days was a trip. Testing tools were nonexistent. Once you had a clean compile, test data was developed and key-punched into cards, JCL was modified, and the test was run. Of course, if the file was greater than 80 characters, first you ran a program to combine multiple cards into an extended file format. Not surprisingly, many transaction files were 80 characters in length. If you were lucky, the test results were printed and analyzed. If you were unlucky—which was most of the time in the beginning—execution terminated, resulting in a core dump. This 144 characters per line printout of the entire computer memory in hexadecimal¹⁰ looked like “01 A9 34 5A D2 88 88” and went on for page after page. Figuring out where your program started and then tracing the execution path was loads of fun!

10.计算机中使用的十六进制 (hex) 数字系统有 16 个符号（基数为 16），而不是标准的十进制（基数为 10）。这 16 个符号分别是 0–9 和 A–F。

10. The hexadecimal (hex) numbering system used in computing has 16 symbols (base 16) rather than the standard decimal (base 10) system. The 16 symbols are 0–9 and A–F.

当时，我们对管理层想要的东西有一个愿景，但技术却受到严重的限制。

In those days we had a vision of what management wanted, but the technology was severely limiting.

我负责实施一套新的会计系统，该系统计划取代软件应用程序和整个帐户编码系统（另一个团队开发了该软件）。由于采用了新的编码系统，工资单等操作系统将在当月开始使用新代码。因此，当我们关闭旧的月末系统并启用新系统时，就无法再恢复了。该项目涉及修改和集成许多子系统，因此实施时间被推迟到九个月。

I managed the implementation of a new accounting system scheduled to replace both the software application and the entire account coding system (another team developed the software). Because of the new coding system, the operational systems, such as payroll, would begin using new codes during the month. As a result, when we turned the old month-end system off, and switched the new one on, there was no going back. The project involved modifying and integrating many subsystems, which pushed the implementation to a nine-month project.

作为项目经理，我的创新是构建一个测试程序，将现有子系统（工资单、应付账款、成本分配）的输出与新子系统或修改后子系统的输出进行比较。我的比较程序很复杂，因为它涉及将数据提供给会计应用程序的操作系统中的所有数据进行映射。当不同的子系统（例如，维护成本系统）准备就绪并开始生成新代码时，测试程序会将新代码映射回旧代码，并将其与正确的映射进行比较——我们会发现大量错误。这是我第一次意识到测试是多么重要和困难。

My innovation as the project manager was to build a test program that compared the outputs of the existing subsystems (payroll, accounts payable, cost allocation) with the outputs of the new or modified ones. My comparison program was complex, since it involved mappings for all the data in the operational systems feeding data to the accounting application. As different subsystems (for example, the maintenance cost system) became ready and started generating new codes, the testing program would map the new codes back to the old, and compare them with the correct mapping—and we would find tons of errors. It was my first insight into how critical, and hard, testing was.

随着我们临近可怕的转换日期，我们经常在晚上和周末加班，帮助计算机中心的操作员安装磁带驱动器、即时更正卡片组并重新运行系统。在随后的几年里，由于审计“职责分离”控制，开发人员被禁止参与运营。

As we neared our dreaded conversion date, working nights and weekends, we often helped the operators in the computer center, mounting tape drives, making card deck corrections on the fly, and rerunning the system. In subsequent years, developers were banned from operations due to audit “separation of duties” controls.

项目即将结束的一个晚上，团队吃完晚饭回来，我把车停在了主任预留的车位上。我工作了一整晚，完全忘记了停车的事。第二天早上，我的一位同事告诉我，我遇到了大麻烦，需要尽快去见主任。他是一位粗鲁、传统的高管，所以我很紧张地走进他的办公室，向他道歉，并告诉他我通宵工作的经历。他出乎意料地大方：“任何连续工作 24 小时的人都可以把车停在任何他们想停的地方。把你的车停在原地就行了。”他还感谢了我和团队的辛勤工作。

One evening toward the end of the project, the team returned from dinner, and I parked my car in a director’s reserved spot. I worked all night and completely forgot about the parking. The next morning, one of my colleagues informed me I was in big trouble and needed to go see the director post haste. He was a gruff, traditional executive, so I was nervous as I entered his office, apologized, and told him my story of working all night. He surprised me by being gracious: “Anyone who works 24 hours straight gets to park anywhere they damn well please. Just leave your car where it is.” He also thanked me and the team for our hard work.

即使使用新系统，结清本月的会计账簿也花了三个晚上。11第一天的^第二天早上，情况看起来不太好：令人生畏且复杂的成本会计系统 BUPS（Burden、Utilities 和 Plant Services）中，¹²工作不正常。只有两三个人足够了解这个系统可以排除故障，所以我们找了一个小会议室来讨论解决方案。我当时的经理是一位老派的微观管理者，他走进房间开始试图“修理”东西。由于几乎没睡觉就工作了两天，我无法容忍他的干涉，但我有足够的理智不直接与他对峙。我去找我的朋友 John Fahlberg，他和我经理同级。“在我发怒之前把他带走，”我试图礼貌地说。John 是个温文尔雅的人，他把我的经理领出了房间，并说服他让团队解决问题 — — 我们很快就做到了。

Closing the accounting books for the month, even with the new system, took three nights.¹¹ The morning after the first day, things weren’t looking good: The dreaded, and complex, cost accounting system, named BUPS (Burden, Utilities, and Plant Services),¹² wasn’t working correctly. There were only two or three people who knew this system well enough to troubleshoot it, so we took a small conference room to hash out solutions. My manager at the time was an old-school micromanager, and he walked into the room and started trying to “fix” things. Having worked two days with almost no sleep, I had little tolerance for his interference, but I did have enough sense not to confront him directly. I went to my friend, John Fahlberg, who was on my manager’s level. “Get him out of there before I lose it,” I tried to say somewhat civilly. John, being the suave guy he was, guided my manager out of the room and convinced him to let the team fix the problem—which we did shortly thereafter.

11.计算资源非常昂贵，因此需要在 24 小时内平衡负载。因此，许多操作系统（例如会计）的工作都是在夜间运行的。

11. Computing resources were costly, so balancing loads over a 24-hour period was necessary. Therefore, jobs for many operational systems such as accounting were run overnight.

12。这是一个最先进的成本分配系统，它根据人员数量、仓库面积等各种因素将管理成本分配给生产单位，最终反映在产品（例如汽油、取暖油）成本中。然而，在分配给生产单位之前，管理成本是在管理小组之间分配的 - 例如，会计成本分配给 IT，反之亦然，如此周而复始！这个单一系统在我们的 IBM 360 计算机上运行需要 3-4 个小时。

12. This was a state-of-the-art cost allocation system that allocated administrative costs, based on various factors such as people count, square footage of warehouse space, and many more, to production units, which were eventually reflected in product (e.g., gasoline, heating oil) costs. However, before allocation to the production units, admin costs were allocated among the admin groups—for example, accounting costs to IT, and the reverse, and around and around it went! This single system took 3–4 hours to run on our IBM 360 computer.

该项目取得了巨大的成功，经过九个月每周 60 到 80 小时的工作后，每个人都松了一口气。我的朋友约翰为团队和他们的另一半策划了一场聚会。他不顾老板关于降低聚会成本的建议，举办了一场一流的活动，供应了丰富的海陆大餐。考虑到项目团队投入的大量加班时间，这只是一个小小的让步。

The project was a huge success, and everyone was relieved after nine months of 60- to 80-hour workweeks. My friend John planned a party for the team and their significant others. Ignoring his boss’s suggestion to keep the cost of the party down, he put on a first-class event, replete with surf-and-turf entrees. Considering the enormous number of overtime hours put in by the project team, this was a minor concession.

虽然我在这个项目上的头衔是项目经理，但我对项目管理一无所知，也许除了甘特图是什么样子。与编程一样，我没有接受过正规教育，而且关于这个主题的材料也很少。但我知道其他团队成员有编程经验，了解他们的系统，不需要我进行微观管理。我们有一个最后期限，有很多事情要做；团队只需要一个总体计划。这是项目管理的狂野西部，但我开始对管理风格有所了解。

While my title on this effort was Project Manager, I knew nothing about project management, except perhaps what a Gantt chart looked like. As with programming, I’d had no formal education and there was little material on the topic available. But I knew other team members had programming experience, knew their systems, and didn’t need me micromanaging. We had a deadline, lots to do; the team just needed an overall game plan. It was the Wild West of project management, but I was starting to develop an inkling of management style.

在此期间，大多数系统用户都一无所知，而我们这些计算机先驱者则稍微不那么无知。炼油厂维护部门的一个项目提供了一些线索。那里的经理们想要一个基本的系统来跟踪维护单。像一个优秀的分析师一样，我与几位目前手动执行任务的维护人员进行了交谈，写下了一些规范，然后在大约三个月内开发并测试了 Mark IV 中的系统。我向经理们展示了他们喜欢的各种报告，然后向他们展示了输入表格他们需要填写表格并进行打字。他们回答说：“停止。”“你的意思是我们必须填写这些表格？”我试图解释说，制作报告需要输入数据。他们不高兴，最终放弃了努力。双方对计算机以及如何使计算机有效的知识都处于起步阶段。

During this period, most systems users were clueless, and most of us computer pioneers were marginally less clueless. A project with the refinery maintenance department provided a couple of clues. Managers there wanted a rudimentary system to keep track of maintenance tickets. Like a good analyst, I talked to several maintenance people who currently performed the task manually, wrote down a few specifications, and then developed and tested a system in Mark IV in about three months. I showed the various reports to the managers, which they liked, and then showed them the input forms they would need to fill out and get keypunched. “Cease” was the response. “You mean we have to fill out these forms?” I tried to explain that producing reports required input data. They were not happy and ended up abandoning the effort. The knowledge on both sides about computers and how to make them effective was in its infancy.

成功实施会计系统让我获得了第一份管理工作——晋升为会计组主管，负责工资、应付账款和材料会计等。当时我 28 岁，小组中最年轻的成员是 45 岁，他们都加入了工会。在这个职位上，我了解到 IT 部门和 IT 用户界面业务部门之间的区别。在 IT 部门，我们总是要求业务用户花时间了解他们所做的事情，这样我们就可以构建系统来支持他们的工作。由于 IT 项目时间很长，所以并不总是每天都有压力——当然，直到最后。在业务用户方面，每天都有压力，要赶上工资、会计结账和发票付款的最后期限。我永远不会忘记这些互动的不同动态。

The successful accounting system implementation led to my first management job—promotion to supervisor of an accounting group responsible for payroll, accounts payable, and materials accounting, among other areas. I was 28 years old, and the next youngest person in the group was 45, and they were all unionized. In this role, I learned the difference between being in IT and being on the business side of the IT–user interface. In IT, we were always asking for business users’ time to learn about what they did, so we could build systems to support their efforts. Due to the long IT project timelines, there wasn’t always daily stress—until the end, of course. On the business user side, there were daily stresses of making deadlines for payroll, accounting closes, and invoice payments. I’ve never forgotten the different dynamics of these interactions.

有一次，一名员工抱怨一个粗鲁无礼的供应商要求立即付款（并没有逾期付款），我打电话给供应商副总裁。我说如果他的员工再这样粗鲁无礼，他们以后就再也不会和埃克森做生意了！当然，我没有这样的权力，但他不知道，我的员工很喜欢。这件事为我刚刚形成的管理风格又增添了一点——对每个人都一视同仁。

Once, when a staff member complained about a rude, disrespectful vendor demanding immediate payment (it wasn’t overdue), I called the vendor vice president. I said if his staff were ever rude again, they would never do business with Exxon in the future! Of course, I had no such authority, but he didn’t know that, and my staff loved it. This episode added another bit to my nascent management style—you treat everyone with equal respect.

20 世纪 70 年代初，埃克森公司旗下有 7 家炼油厂：4 家大型炼油厂和 3 家小型炼油厂。大型炼油厂的业务系统组各自开发了系统，而前面提到的会计系统是建立通用性的第一步。这种差异的协调并不容易，因为每个地点都有自己的经营方式，不愿意改变。

In the early 1970s, there were seven Exxon refineries: four large and three smaller ones. The business systems group in the large ones had developed systems independently and the accounting system mentioned earlier was an initial step in instituting commonality. This reconciliation of differences wasn’t easy, as each location had its own way of doing business and was reluctant to change.

为了协助整个炼油部门的 IT 系统合理化，在休斯顿炼油主管办公室设立了业务系统协调员职位。13^当时，与许多公司一样，IT 向主管汇报。后来，随着 IT 成为企业不可或缺的一部分，IT 组织将向首席信息官 (CIO) 汇报，然后首席信息官向首席执行官 (CEO) 汇报。接受协调员的工作，我致力于整合业务系统，其中会计系统是一个很好的开端。软件系统的整合最终导致了炼油厂计算机设施的整合——这在当时是一项重大成就。

To assist in rationalizing IT systems throughout the refining department, the position of business systems coordinator was established in the Refining Controller’s office in Houston.¹³ As in many companies at that time, IT reported to the controller. Later, as IT became an integral part of businesses, IT organizations would report to a chief information officer (CIO), who then reported to the chief executive officer (CEO). Accepting the coordinator’s job, I worked to consolidate business systems, of which the accounting system was an excellent start. Consolidation of the software systems eventually led to consolidation of the refinery’s computer facilities—a major accomplishment in those days.

13.由于当时最重要的应用是会计和财务导向的，因此大多数 IT 部门都向控制员（现在我们使用术语首席财务官 [CFO]）汇报。

13. Because the most important applications at that time were accounting and finance oriented, most IT departments reported to the controller (now we use the term chief financial officer [CFO]).

由于我们属于财务主管组织，所以我偶尔会做一项工作，那就是合并季度炼油厂财务报告。有一天，我接到了公司层面的同事打来的电话，他负责合并所有部门（炼油、勘探、生产）的报告：“恭喜你，你的数字只差了 10 亿美元。”“嗯，”我说，“只差一位数。”

Since we were in the controller’s organization, one of my infrequent tasks was consolidating quarterly refinery financial reports. One day, I received a call from my counterpart at the corporate level who consolidated reports from all the divisions—refining, exploration, production: “Congratulations, your numbers are off by only a billion dollars.” “Well,” I said, “it was only one digit.”

这是一项影响性工作，而不是管理性工作，因为每个炼油厂的业务系统主管都不为我工作。即便如此，我仍需要他们的帮助来规划如何将炼油厂的 IT 系统整合到一起。

This was an influence job, not a managerial job, as the business systems supervisors in each refinery didn’t work for me. Even so, I needed their help in planning how to bring the refinery IT systems into a modicum of commonality.

埃克森美孚至奥格尔索普

Exxon to Oglethorpe

1976 年，在埃克森美孚工作了近六年后，我搬到了亚特兰大，做了几份短期工作后，最终进入奥格尔索普电力公司担任软件开发经理。

In 1976, after nearly six years with Exxon, I moved to Atlanta, where, after a couple of short-term jobs, I ended up at Oglethorpe Power Company as software development manager.

我在亚特兰大的一家银行工作过一段时间，那里的计算机操作人员每天都会将成堆的计算机打印件放在行长的办公桌上，而我参与了该银行的第一个国际银行系统。这个项目包括前往纽约市的花旗银行，调查该银行在 DEC 超级计算机上运行的最先进的国际银行系统。结合我在花旗银行学到的知识以及与国际银行家讨论时获得的知识，我撰写了一份提案，建议采用新的国际银行系统来处理外汇、信用证和其他国际银行交易。我喜欢与国际员工一起工作，因为他们是银行家中比较随和的人。

During a brief stint in an Atlanta bank, where computer operations staff deposited piles of computer printouts on the president’s desk each day, I worked on their first international banking system. This project included a trip to Citibank in New York City to investigate its state-of-the-art international banking system running on a DEC superminicomputer. Combining what I learned at Citibank with the knowledge I had gleaned in my discussions with our international bankers, I wrote a proposal for moving forward with new international banking systems for processing foreign exchange, letters of credit, and other international banking transactions. I liked working with international staff, as they were laid-back as bankers go.

但其他人就没那么悠闲了，当我在一家保守的银行被质问是否遵守标准和程序时，我了解到了这一点。看来我的旅行和提案费用已经超出预算 10% 以上的限额。我甚至不知道我有预算，但我收到了一封会计人员发来的催款信。如果不是从一本会计账簿上复制并装订在信上的五到六页纸，我可能会忽略它，这暗示我要好好研究一下成本会计。我邀请那家伙到我的办公室聊一聊。

But others were not so laid back, as I learned when confronted about my adherence to standards and procedures in a conservative bank. It seems my travel and proposal costs had exceeded my budget by more than the 10% limit. I hadn’t even known I had a budget, but I received a dunning letter from a guy in accounting. I would have ignored it were it not for the five to six pages copied from an accounting book and stapled to the letter, which suggested I bone up on my cost accounting. I invited the guy to my office for a chat.

“我墙上的是什么？”我指着一张裱框的文件问道。

“What is that on my wall?” I asked, pointing to a framed document.

他回答道：“看起来像是注册会计师证书。”

“It looks like a CPA certificate,” he replied.

“你有吗？”这是我的第二个问题。

“Do you have one?” was my second question.

“不。”

“No.”

“好吧，在你这么做之前，不要再给我发会计账簿了！”

“Well, until you do, don’t send me more pages from accounting books!”

虽然我提出的发展国际银行体系的提议得到了广泛接受，但那时我的不墨守成规的一面与银行业职业发生了冲突，因此我很快就转向了一种不那么死板的文化。

Although my proposal on developing an international banking system was well received, by that time my nonconformist side conflicted with a banking career, so I quickly moved on to a less rigid culture.

OGLETHORPE POWER是一家新成立的发电、输电和配电合作社，为佐治亚州农村地区的电力公司提供服务（我本科时主修电力系统工程）。我的软件开发经理职位就像一个初创职位，因为我要组建员工队伍并实施方法。

OGLETHORPE POWER was a newly formed power generation, transmission, and distribution cooperative serving power companies in rural Georgia (in my undergraduate program, I majored in power systems engineering). My software development manager job was like a start-up position, as I got to build my staff and implement methods.

^{我的部门经理以前曾在安达信咨询公司}工作过，所以我们采用了该公司的 Method/1 方法，这种方法在当时是先进的。虽然 Method/1 旨在作为软件项目的项目管理工具，但它并不包括具体的开发方法。例如，它包含“定义文件格式”和“填写文件布局表单”等任务，但没有实际定义它们的方法。

My department manager had worked for Andersen Consulting¹⁴ in the past, so we adopted that firm’s Method/1 methodology, which was advanced for the times. While Method/1 was intended as a project management tool for software projects, it didn’t include specific development methods. For example, it contained tasks like “Define a file format” and “Complete a file layout form,” but had no methods for actually defining them.

14 . 安达信最初是一家会计师事务所。安达信咨询集团不断发展壮大，最终分拆为埃森哲。

14. Arthur Andersen was primarily an accounting firm. The Andersen Consulting group grew and was eventually spun off as Accenture.

我曾参加过 Yourdon, Inc. 的一些结构化技术课程，并希望将其纳入我们公司的开发流程。在与安达信的一位顾问讨论结构化技术时，他建议我们除了 Yourdon 方法之外，还可以看看 Warnier-Orr 方法。随后，我请 Ken Orr 来教我们他的方法论和方法。虽然这些方法最初是由法国人 Jean-Dominique Warnier 创建的，但 Ken Orr 补充了原始想法并在美国推广它们。这些图表显示了层次结构、顺序、重复和交替等结构。该方法侧重于从输出开始，并找出产生这些输出的流程。这种强调输出而不是输入的概念一直伴随着我，最终延伸到敏捷时代的成果概念。

I had taken a few courses in structured techniques from Yourdon, Inc., and wanted to incorporate them into our company’s development process. In a structured techniques discussion with one of the Andersen consultants, he suggested we look at the Warnier-Orr approach in addition to the Yourdon one. Subsequently, I brought Ken Orr in to teach us about his methodology and methods. While these methods were initially created by Frenchman Jean-Dominique Warnier, Ken Orr added to the original ideas and popularized them in the United States. The diagrams showed constructs such as hierarchy, sequence, repetition, and alternation. The methodology focused on starting with the outputs and working out the flows that produced those outputs. This emphasis on outputs rather than inputs was a concept that stuck with me, eventually extending to the concept of outcomes in the Agile era.

我的员工接受了 Warnier-Orr 方法，我们用它交付了几个应用程序。我们还购买并使用了 Ken 的软件包 Structure(s)，这是计算机辅助软件工程 (CASE) 工具的前身。我的一名员工对此感到兴奋。一位经验丰富的程序员，他说：“这是我第一次编写 COBOL 程序，第一次运行时没有出现编译器错误。”这个系统是我们第一次完整使用 Warnier-Orr 技术。它很成功，设计得很好。然而，它在我的脑海里种下了一颗小小的怀疑的种子：“它的开发时间肯定比我预期的要长。”

My staff embraced the Warnier-Orr approach, and we delivered several applications using it. We also purchased and used Ken’s software package called Structure(s), a precursor to computer-aided software engineering (CASE) tools. One member of my staff got excited. An experienced programmer, he remarked, “This is the first time I’ve ever written a COBOL program that didn’t have a compiler error the first time through.” This system was our first complete life-cycle use of the Warnier-Orr techniques. It was successful and well designed. However, it sowed a tiny seed of doubt in the back of my mind: “It sure took a longer development time than I expected.”

1978 年，我的写作生涯始于一篇发表的文章，当时《管理信息系统季刊》上发表了“更有效地解决设计问题” 。有趣的是，这篇论文不是关于软件开发的，而是关于群体问题解决的过程。在 20 世纪 70 年代和 80 年代，我在MISQ、Auerbach Reports、Datamation（Highsmith，1981 年）和《商业软件评论》（Highsmith，1987 年）上发表了其他文章。

During 1978, my writing career began with a published article, when “Solving Design Problems More Effectively” appeared in Management Information Systems Quarterly. Interestingly, this paper was not about software development, but rather about a process for group problem solving. During the 1970s and 1980s, I published other articles in MISQ, Auerbach Reports, Datamation (Highsmith, 1981), and Business Software Review (Highsmith, 1987).

软件开发

Software development

在早期的狂野西部时代，软件流程、工具、参考书和培训都很稀缺。我从 IBM COBOL 手册中学习，并经常冲进 Ed（来自 Esso）的办公室询问问题。我的大部分知识都来自经验——有好的也有坏的。由于 Ed 的风格安静，很难与他沟通，但他的经验使他成为我早期的一位宝贵导师。

In the early Wild West era, software processes, tools, reference books, and training were scarce. I learned from the IBM COBOL manual and rushed frequently into Ed’s (from Esso) office to ask questions. Most of my knowledge acquisition came through experiences—both good and bad. Owing to his quiet style Ed was difficult to communicate with, but his experience made him an invaluable early mentor to me.

在埃克森美孚业务集团，有一位从技术系统调入的程序员。他的技术编程一直使用 Fortran，¹⁵因此他用 COBOL 编写了他的第一个业务应用程序，一个工资单系统，但使用了类似 Fortran 的数据名称。由于语言限制，Fortran 程序员习惯于使用“EMPRT2”这样的数据名称，¹⁶而不是像“Employee-Pay-Rate2”这样的 COBOL 数据名称。当他转行时，他使用 Fortran 数据名称编写的 COBOL 程序带来了难以言喻的维护难题。这又是一次狂野西部之旅。

In the Exxon business group, there was a programmer who transferred in from technical systems. His technical programming had been in Fortran,¹⁵ so he wrote his first business application, a payroll system, in COBOL, but used Fortran-like data names. Fortran programmers were accustomed to using data names like “EMPRT2” because of language restrictions,¹⁶ rather than COBOL data names like “Employee-Pay-Rate2.” His COBOL programs using Fortran data names caused untold maintenance headaches when he moved on. More Wild West.

15. Fortran (FORMula TRANslator) 是一种早期用于科学和工程应用的计算机语言。

15. Fortran (FORMula TRANslator) was an early computer language used for scientific and engineering applications.

16. Fortran 中的变量名限制为六位数字，即 a–z 和 0–9。在大型系统中，这种限制会导致奇怪的变量名。此外，COBOL 是一种面向文件的语言，专为业务系统而设计。Fortran 是一种面向变量的语言，专为科学和工程计算而设计。IBM 提供了 PL/1 作为单一语言解决方案来替代 Fortran 和 COBOL，但它并未得到广泛使用。

16. Variable names in Fortran were limited to six digits, a–z and 0–9. In a large system, this limitation led to bizarre variable names. In addition, COBOL was a file-oriented language, designed for business systems. Fortran was a variable-oriented language designed for scientific and engineering calculations. IBM offered PL/1 as a one-language solution to replace both Fortran and COBOL, but it was not widely used.

一个臭名昭著、阴险甚至危险的 COBOL 语句体现了这个时代的本质——ALTER 语句。想想一个程序语句——转到 CALC-Pay-Status。好的，到目前为止。现在到了有趣的部分。在程序打印输出的三页下（记住，当时只有纸质输出），一个基于某个变量的 ALTER 语句将初始 GO TO 目标修改为 Go To ALT-CAL-PAY-STATUS 之类的内容。哇哦。现在想想一个包含 1,000 条语句的 COBOL 程序，其中包含 50 个这样的 ALTER-GOTO 构造，以及遵循逻辑的难度。你至少需要 25 个手指才能跟上。维护这些程序是一场噩梦 — — 通常留给下一个可怜的人。

One infamous, insidious, and even dangerous COBOL statement epitomizes the nature of this era—the ALTER statement. Think of a program statement—Go To CALC-Pay-Status. Okay, so far. Now comes the fun part. Three pages down on the program printout (remember, only paper output in those days), an ALTER statement, based on some variable, modifies the initial GO TO destination to something like Go To ALT-CAL-PAY-STATUS. Wow. Now think of a COBOL program of 1,000 statements containing 50 of these ALTER-GOTO constructs and the difficulty in following the logic. You needed at least 25 fingers to keep up. Maintenance of these programs was a nightmare—usually passed along to the next poor soul.

在随机访问数据库出现之前的串行磁带文件时代，我们使用了一些技术，例如根据变量（例如记录类型）为单个数据字段分配多种数据类型。如果记录类型为“商业”，则字段 4 可能用于“颜色”，如果记录类型为“零售”，则字段 4 可能用于“尺寸”。日期字段通常为两位数，这导致了 30 年后出现的 Y2K 问题。为什么？程序员为什么要制造这些维护噩梦？

During the time of serial tape files, prior to random-access databases, we used techniques like assigning a single data field multiple data types depending on a variable such as the record type. Field 4 might be used for “color” if the record type was “commercial” and for “size” if it was “retail.” Date fields were often two digits, which precipitated the Y2K problem 30 years later. Why? Why would programmers create these maintenance nightmares?

如今，手机拥有 128 MB 内存，可以访问廉价的数 TB 云数据。1971 年推出的第一款英特尔芯片的时钟速度略低于 1 兆赫。17^如今，芯片时钟速度可以超过 5 千兆赫。18在狂野西部时代，计算机速度非常缓慢，内存价格高昂。作为这一时期的程序员，我们需要尽可能节省每个字节和赫兹。我们必须知道哪些 COBOL 语句快，哪些慢。这导致了 ALTER 语句的过度使用，因为它们速度很快^。

Today, cell phones have 128 MB of memory and access to inexpensive terabytes of cloud data. The first Intel chip, introduced in 1971, had a clock speed of a little less than 1 megahertz.¹⁷ Today, chip clock speeds can exceed 5 gigahertz.¹⁸ In the Wild West era, computer speeds were glacial and memory was exorbitantly expensive. As programmers during this period, we needed to save every byte and hertz we could. We had to know which COBOL statements were fast and which were slow. This contributed to the overuse of ALTER statements, because they were fast.

17。在本文中，赫兹不是指汽车租赁公司，而是指每秒周期数的频率测量单位。1 兆赫 (MHz) 等于 100 万赫兹；1 千兆赫等于 1,000 MHz 或 100 万赫兹。

17. In this context, hertz is not a car rental company, but rather a frequency measure of cycles per second. One megahertz (MHz) equals 1 million Hz; 1 gigahertz equals 1,000 MHz or 1 million Hz.

18. 2022年，橡树岭国家实验室超级计算机突破1拍赫兹（1×10 ¹⁵ Hz）。

18. In 2022, Oakridge National Labs supercomputer exceeded 1 petahertz (1 × 10¹⁵ Hz).

这一时期的开发工具包括流程图和层次化输入输出 (HIPO) 图。20 世纪 70 年代中后期，数据流图和其他结构化方法应运而生^。19

During this period, development tools included flowcharts and hierarchical input–output (HIPO) diagrams. In the mid- to late 1970s, data flow diagrams and other structured methods emerged.¹⁹

19、这些图表在第 3 章中进行了解释。

19. These diagrams are explained in Chapter 3.

1978 年，我读了 Tom DeMarco (1978) 的书《结构化分析和系统规范》，并参加了 Steve McMenamin 教授的 Yourdon 结构化分析课程。20^我立即转向了这种发现和记录需求的系统方法。这种“工程”方法激发了我的热情。当我接受 Oglethorpe 软件开发经理的工作时，我知道采用这些方法是我的使命的一部分。

In 1978 I read Tom DeMarco’s (1978) book, Structured Analysis and System Specification, and attended a Yourdon class on structured analysis taught by Steve McMenamin.²⁰ I was an instant convert to this systematic approach to uncovering and documenting requirements. This “engineering” approach fueled my enthusiasm. When I accepted the job as software development manager at Oglethorpe, I knew incorporating these methods was part of my mission.

20.有关这些主题的更多信息请参见第 3 章。

20. More on these topics in Chapter 3.

管理趋势

Management trends

我追求管理学位的初衷是出于好奇，也因为我越来越觉得，我希望更好地理解软件开发背景下的管理和领导力。总体和项目管理趋势塑造了早期以及随后时代的软件开发。

My pursuit of a management degree arose from curiosity and a growing sense I wanted a better understanding of management and leadership as a context for software development. General and project management trends shaped software development in the early years, as well as in following eras.

在狂野西部时代，僵化的文化是常态——等级森严、指挥控制，专注于规划和执行这些计划。工程领域取得了长足进步，其假定的可预测性逐渐渗透到管理思想中。企业普遍以财务为衡量标准——一如既往，由华尔街推动。软件项目的成功取决于完成情况和成本。交付软件本身就被认为是成功，但进度对项目来说也至关重要。成本当然很重要，但与系统启动和运行相比，成本是次要的。

Inflexible cultures were the norm during the Wild West era—hierarchical, command-control, focused on planning and execution of those plans. Great strides were being made in engineering, and its assumed predictability crept into management thinking. Businesses were universally measured in financial terms—as always, driven by Wall Street. Software project success was measured by completion and cost. Just getting software delivered was considered a success, but schedule was also essential for projects. Cost was certainly important, but was secondary to getting systems up and operating.

企业经营的前提是——无论正确与否——世界名义上是可以预测的，如果计划未能实现，问题在于执行，而不是规划。优秀的经理和高管能把事情做好——故事结束。新生的 IT 世界不太可预测，这让 IT 高管陷入困境，因为管理层很少考虑到计算机和软件仍处于实验性质。

Businesses operated on the premise—correct or not—that the world was nominally predictable and if plans failed to materialize, the problem was execution, not planning. Good managers and executives got things done—end of story. The nascent IT world was less predictable, which put IT executives in the hot seat because little allowance was given by general management for the still experimental nature of computers and software.

从管理变革如何影响软件开发的角度来看，有四个因素显得很重要：行业变革、工作类型、管理风格和工人类别。

Looking at how management evolution impacted software development, four factors appeared important: industry evolution, work type, management style, and worker category.

随着 20 世纪初工业时代的到来，弗雷德里克·温斯洛·泰勒等研究人员提出了“科学管理”这一术语，赞扬了精确测量和严格、规范的工作职责的优点。将组织视为机器的观点已根植于管理文化中，优化这些机器已成为一项关键的管理目标。

As the industrial age blossomed in the early twentieth century, researchers like Frederick Winslow Taylor introduced the term scientific management, extolling the virtues of precise measurements and rigorous, prescriptive job duties. The view of the organization as machine became embedded in the management culture, and optimizing those machines became a key management goal.

后来，管理理论开始根据道格拉斯·麦格雷戈和彼得·德鲁克等人的工作而发生变化。我们听说过各种类别的 GOAT（史上最伟大的人物）——但谁会获得文学奖呢？虽然这可能取决于你使用谁的名单，但普遍的共识是马塞尔·普鲁斯特的《追忆似水年华》^。21如果管理理论中有 GOAT，那很可能是彼得·德鲁克。德鲁克在他的时代写了 39 本书，并于 1959 年创造了知识工作一词。他被称为现代管理之父，他对管理的定义如下：“管理就是“一个多用途的机构，管理业务、管理管理者、管理工人和工作”（德鲁克，1954 年）。这个简洁的定义有助于我们评估工作变化、工人变化、管理者变化以及管理者的管理者变化等随时间推移而发生的变化。德鲁克创造了知识工作这一术语，这表明工作的本质正在发生变化。

Later, management theory began to change based on the work of individuals like Douglas McGregor and Peter Drucker. We hear about GOATs (greatest of all time) in various categories—but who would take the prize in literature? While it might depend on whose list you use, the general consensus is In Search of Lost Time by Marcel Proust.²¹ If there is a GOAT in management theory, it could well be Peter Drucker. In his time, Drucker wrote 39 books and coined the term knowledge work in 1959. Called the father of modern management, he defined management as follows: “Management is a multi-purpose organ that manages business and manages managers and manages workers and work” (Drucker, 1954). This succinct definition helps us assess changes over time as work changes, workers change, managers change, and managers of managers change. Drucker’s coining of the term knowledge work signaled that the very nature of work was changing.

21.取决于你同意哪一个 Google 列表。

21. Depends on which Google list one concurs with.

“组织就像机器”——这种来自我们工业时代的形象继续给管理蒙上阴影。管理者认为稳定是正常情况，而变化是“不寻常的状态”，丽塔·麦格拉斯在 2014 年《哈佛商业评论》的一篇文章中写道。麦格拉斯确定了管理的三个时代——执行、专业知识和同理心。“如果组织在执行时代是为了创造规模，在专业知识时代是为了提供先进的服务，那么今天许多组织都希望组织能够创造完整而有意义的体验”（麦格拉斯，2014 年）。这些管理风格类别为我们讨论软件开发时代带来了另一个维度^。22

“Organization as machine”—this imagery from our industrial past continues to cast a long shadow over management. Managers assumed stability was the normal situation and change was the “unusual state,” writes Rita McGrath in a 2014 Harvard Business Review article. McGrath identifies three ages of management—execution, expertise, and empathy. “If organizations existed in the execution era to create scale and in the expertise era to provide advanced services, today many are looking to organizations to create complete and meaningful experiences” (McGrath, 2014). These management style categories bring another dimension to our discussion of the software development eras.²²

22.第 8 章重新审视了麦格拉斯的风格。

22. McGrath’s styles are revisited in Chapter 8.

不幸的是，除了她在《哈佛商业评论》上发表的文章外，我再也没有找到关于麦格拉斯的更多资料。此外，关于共情风格也存在争议。23^即便如此，我还是喜欢麦格拉斯用来对管理时期进行分类的词语。虽然命令控制这个标签经常被应用于传统管理，但最近的风格名称都没有成为“唯一”术语。领导协作、适应性领导、敏捷领导、管理 3.0、专家领导等名称都出现在过去的二十年里。所以，我将提名麦格拉斯的“共情”作为现代管理的最佳名称。

Unfortunately, I never found further McGrath material other than her Harvard Business Review article. Moreover, there is debate about the empathetic style.²³ Even so, I liked the words McGrath used to categorize management periods. While the label command-control has often been applied to traditional management, none of the recent style names has emerged as “the” term. Names such as leadership-collaboration, adaptive leadership, Agile leadership, Management 3.0, savant leadership, and others have all appeared in the last two decades. So, I will nominate McGrath’s “empathy” as the best name for modern management.

23. “领导层越来越注重同理心的趋势无疑是当前最受争议的话题之一，但这一趋势也存在着两派截然不同的看法”( www.business.com )。

23. “Easily one of the most debated topics currently, the trend of increasing empathy in leadership has two very opinionated sides” (www.business.com).

世界经济论坛首席执行官克劳斯·施瓦布提出了一种看待工作演变的方式。施瓦布的四个时代以科学技术的进步为中心：

KLAUS SCHWAB, CEO of the World Economic Forum, proposed a way of looking at the evolution of work. Schwab’s four ages are centered on the advances of science and technology:

• 第一：机械生产时代

• First: The Age of Mechanical Production

• 第二：科学与大规模生产时代

• Second: The Age of Science and Mass Production

• 第三：数字革命

• Third: The Digital Revolution

• 第四阶段：想象时代

• Fourth: The Imagination Age

^{随着科学和大规模}生产时代的到来，组织变得越来越大，需要一种管理多层级组织的方法，从基层主管到高管。标准化流程、质量控制和专业化分工等做法得到了广泛应用。优化——效率、一致性、可测量性、可预测性——是目标。这种方法被称为命令控制管理，它定义了执行时代。这是工业工人从事体力劳动的时代。

As the Age of Science and Mass Production²⁴ got under way, organizations got bigger and needed a way to manage multilayered organizations, from ground-level supervisors to executives. Practices such as standardized processes, quality control, and specialization of labor were widely applied. Optimization—efficiency, consistency, measurability, predictability—was the goal. This approach, dubbed command-control management, defined the Execution Age. This was the age in which industrial workers were performing physical work.

24.我没有描述第一时代，因为它与软件开发无关。

24. I didn’t describe the First Age because it wasn’t relevant to software development.

随着数字革命，计算机技术从大型机发展到小型机再到个人计算机，扩大了计算能力的使用范围。心理学和社会学等其他学科的概念开始渗透到管理理论中，但这个时代主要发挥专业知识的作用，其特点是再造、六西格玛和管理层管理等概念。

With the Digital Revolution, computer technology evolved from mainframes to minicomputers to personal computers, broadening access to computing power. Concepts from other disciplines such as psychology and sociology began to creep into management theory, but this age primarily brought expertise into play, characterized by the concepts of reengineering, Six Sigma, and MBO.

软件开发将在这一时期添加自己的术语——即瀑布和纪念碑方法论。随着技术（包括软件、医学、计算机、材料和计算设备）的使用激增，对知识工作者的需求也随之增加。随着知识工作的扩展，员工们开始反抗现有的经理与下属的关系，这促使早期的敏捷主义者专注于构建以人为本的工作场所。为了认识到这一变化， 《自适应软件开发》（Highsmith，2000 年）使用了“领导-协作”管理这一术语来描述这个时代的实践，与早期的“命令-控制”形成对比。

Software development would add its own terms in this period—namely, waterfall and Monumental Methodologies. As the use of technology, including software, medicine, computers, materials, and computing devices, exploded, so did the need for knowledge workers. As knowledge work expanded, employees rebelled against existing manager–subordinate relationships, which drove early agilists to focus on building person-centric workplaces. In recognition of this change, Adaptive Software Development (Highsmith, 2000) used the term “leadership-collaboration” management, in contrast to the earlier “command-control,” to characterize practices of this age.

施瓦布没有设定第四次工业时代的时间框架，也没有明确将其称为想象时代，尽管他的著作中多次提到想象力和创新。他通过变化的速度、技术的快速发展和融合所导致的变化的广度和深度以及系统影响（参考国际社会系统）来定义这个时代。要在这个时代繁荣发展，我们需要重新定义“工作”，了解知识工作者和创新工作者之间的差异，并知道如何以一种鼓励想象力和创造力的富有同理心的方式领导、组织和管理。

Schwab doesn’t set the time frame for the fourth industrial age, nor does he explicitly name it the Imagination Age, although there are references to imagination and innovation in his work. He defines this age by the velocity of change, the breadth and depth of change caused by the rapid evolution and integration of technology, and the systems impact, referring to international sociological systems. To prosper in this era, we will need to define “work” yet again, understand the differences between knowledge workers and innovation workers, and know how to lead, organize, and manage in an empathetic way that encourages imagination and creativity.

想象时代是数字革命之后的时期，随着人工智能、生物技术、机器人技术、量子计算和机器人技术等技术融入我们的世界，创造力和想象力成为经济价值的主要创造者。

The Imagination Age is the period beyond the Digital Revolution, where creativity and imagination become the primary creators of economic value, as technologies such as artificial intelligence, biotechnology, robotics, quantum computing, and robotics become integrated into our world.

最终，工人被分为三类：工业、知识和创新。随着工作性质的变化，所需工人的类型也发生了变化，这反过来又改变了经理和高管（经理的经理）看待和与劳动力互动的方式。

Eventually, workers were classified into three types: industrial, knowledge, and innovation. As the nature of work changed, the types of workers required changed, which in turn changed the way managers and executives (managers of managers) viewed and interacted with the workforce.

回想一下，在新冠疫情爆发之前，你对未来的确定性可能有何感受。那么现在呢？疫情的连锁反应尚不明确，而且在完全爆发之前，我们基本上无法知晓。许多变化在 2020 年之前就已经出现，而疫情只是加速了这些变化。随着不确定性的增加，人们开始理论化如何模拟不确定性，并设计工具和方法来管理它。

REMEMBER HOW YOU MIGHT have felt about the certainty of the future before the COVID-19 pandemic. And now? The ripple effects of the pandemic are unknown and largely unknowable until they fully play out. Many of these changes were emerging before 2020, and the pandemic just accelerated them. As uncertainty has increased, people have begun to theorize ways to model uncertainty and devise tools and methods to manage it.

曾在 IBM 高级商业研究所工作的 Stephan H. Haeckel于 1993 年在《哈佛商业评论》上发表了一篇文章，并在 1999 年出版的《适应性企业》 （Haeckel，1999 年）一书中进一步阐述了他的思想。他的观点是：组织需要从计划和执行转变为感知和响应未来的方法。感知和响应使组织能够感知外部世界，快速响应，并利用反馈来启动下一个周期。致力于计划和执行的组织过于痴迷于计划，以至于偏离计划的行为被视为错误而不是机会。

Stephan H. Haeckel, who worked at the IBM Advanced Business Institute, published a Harvard Business Review article in 1993 and went on to further explain his ideas in his book Adaptive Enterprise in 1999 (Haeckel, 1999). His message: Organizations needed to move from a plan-and-execute to a sense-and-respond approach to the future. Sense-and-respond enables organizations to sense the outside world, respond quickly, and use feedback to initiate the next cycle. Organizations dedicated to plan-and-execute become so plan obsessed that deviations from the plans are considered mistakes rather than opportunities.

柯达为何没有对数码相机的威胁作出反应？数码相机是一夜之间出现的，还是柯达错过了市场线索？Netflix 为何取代百视达？百视达难道没有注意到 Netflix 不断上升的电影租赁市场份额？在瞬息万变的商业和技术环境中，感知可能极其困难。什么是噪音？噪音累积到什么时候会达到警报级别？丽塔·麦格拉斯在其最新著作《洞察角落：如何在商业拐点发生之前发现它们》（2019 年）中对这个难题进行了深入分析。在尝试整理和分析数据流时，您需要了解背景信息——您在哪个领域工作？

Why didn’t Kodak respond to the digital camera threat? Did digital cameras appear overnight, or did Kodak miss market cues? Why did Netflix oust Blockbuster? Didn’t the latter pick up on Netflix’s rising market share of movie rentals? Sensing, in our fast-moving business and technology environment, can be extremely difficult. What is noise? When does accumulated noise raise to the level of alarm? In her latest book, Seeing Around Corners: How to Spot Inflection Points in Business Before They Happen (2019), Rita McGrath provides insight into this difficult question. In attempting to sort through and analyze streams of data, you need context—what arena are you playing in?

戴夫·斯诺登 (Dave Snowden) 设计了一种在支持决策的背景下思考不确定性的方法。1999 年，斯诺登从他对复杂性理论的研究中提取了 Cynefin 模型。斯诺登的模型敏捷社区已经接受了并广泛使用了这一模型。对于每个类别的变更，斯诺登都提出了一种实践类型。他的模型确定了五种变更类别或类型：

Dave Snowden devised a way to think about uncertainty in a context that supports decision making. In 1999, Snowden introduced the Cynefin model derived from his study of complexity theory. Snowden’s model has been embraced and widely used by the agile community. With each category of change, Snowden proposed a practice type to use. His model identifies five categories, or types, of change:

• 显而易见，最佳实践就足够了

• Obvious, for which best practices suffice

• 复杂，需要采用良好做法

• Complicated, for which good practices are used

• 复杂，最适合采用新兴实践

• Complex, for which emergent practices are best

• 混乱，需要新颖的做法

• Chaotic, which requires novel practices

• 疾病，治疗方法可能不为人知

• Disorder, for which practices might be unknown

随着经济、企业和技术从 1980 年代的复杂演变为 2000 年代的复杂，再演变为混乱，斯诺登的框架帮助我们理解了在从结构化到敏捷开发的过渡中，应对不确定性所发挥的作用。在本书中，我将使用 Cynefin 模型作为商业和技术世界中战略性、高层变化的指标。在战术、项目和产品层面，我将在第 6 章中介绍探索因素 (EF) 。这两种“方法”——Cynefin 和 EF——提供了管理不确定性的工具。

As economies, businesses, and technologies evolved from somewhat complicated in the 1980s to complex, and then to chaotic in the 2000s, Snowden’s framework helps us understand the role that combating uncertainty played in the transition from structured to agile development. In this book, I will use the Cynefin model as an indicator of strategic, high-level changes in the business and technology worlds. At the tactical, project, and product levels, I will introduce the exploration factor (EF) in Chapter 6. These two “methods”—Cynefin and EF—provide tools for managing uncertainty.

表 2.1总结了四个软件开发时代这些因素的变化，并帮助我们理解方法和方法论为何会如此演变。在我从结构化方法向敏捷方法演变的过程中，这些框架帮助我为工作提供了有用的背景。

Table 2.1 summarizes the changes in these factors over the four software development eras and helps us understand why methods and methodologies evolved as they did. During my evolution from structured to agile methods, these frameworks helped me put useful context around my work.

在狂野西部时代后期，我开始深入研究项目管理实践。虽然项目管理历史悠久，但与软件开发相关的实践直到 20 世纪 50 年代和 60 年代才出现。甘特图（任务和进度表）在 20 世纪 30 年代早期的胡佛大坝等项目中得到了成功应用。这些早期的其他大型项目包括 20 世纪 40 年代开发核弹的曼哈顿计划。伯纳德·施里弗 (Bernard Shriever) 在美国空军服役期间，于 1954 年首创了项目管理一词。

TOWARD THE LATTER HALF of the Wild West era, I began to delve into project management practices. While project management had a long history, practices relevant to software development emerged only in the 1950s and 1960s. Gantt charts (task and schedule) were used successfully on projects such as the Hoover Dam in the early 1930s. Other large projects in these early years included the Manhattan Project to develop nuclear bombs in the 1940s. Bernard Shriever, while in the U.S. Air Force, was credited with originating the term project management in 1954.

现代项目管理技术的基石是项目评估技术 (PERT)，该技术因海军成功建造北极星潜艇而广为人知。杜邦公司于 1958 年发明了 PERT 和关键路径法 (CPM)，开始在美国航空航天、建筑和国防工业中使用。工作分解结构 (WBS) 的使用始于 20 世纪 60 年代初。项目管理协会 (PMI) 成立于 1969 年，旨在研究和推广项目管理实践。20 世纪 60 年代最著名的项目是阿波罗计划（1963-1972 年），NASA 成功领导了六次月球探测任务。尽管我在阿波罗任务中只扮演了很小的角色，但这次经历让我高兴地说：“我的第一个项目很成功。”

The cornerstone of modern project management techniques was the Program Evaluation Technique (PERT), popularized by the Navy’s successful use building Polaris submarines. PERT and Critical Path Method (CPM), invented in 1958 at Du Pont, began to be used in the U.S. aerospace, construction, and defense industries. The use of work breakdown structures (WBS) began in the early 1960s. The Project Management Institute (PMI) was founded in 1969 to do research into and promote project management practices. The most famous project undertaken in the 1960s was the Apollo Project (1963–1972), in which NASA successfully led six missions to explore the moon. Even though I had an exceedingly small part in the Apollo mission, this experience provided me with a happy quip: “My first project was a success.”

时代观察

Era observations

20 世纪 60 年代和 70 年代为软件开发的后续时代奠定了基础。计算机性能开始实现指数级提升。随机存取存储设备数量成倍增加。核心存储器从工人手动将电线穿过一组微小的环形“甜甜圈”发展而来。人机交互开始稳步发展。

The 1960s and 1970s set the stage for subsequent eras in software development. Computer performance began to realize exponential improvements. Random-access storage devices multiplied. Core memory evolved from workers manually feeding wires through sets of tiny toroid “doughnuts.” Person–computer interactions began their steady evolution.

在这个时代的早期，我们可能会将软件开发称为“临时的”，但先驱者们致力于将早期的方法转变为一门工程学科。到这个时代的末期，结构化方法和项目管理方法开始为交付工作软件的过程带来更好的组织和控制；我们可以将它们称为“高级临时的”。下一个时代将在此基础上发展。

Through the early years of this era, we might label software development as “ad hoc,” but pioneers worked on early methods they envisioned turning into an engineering discipline. By the end of the era, structured methods and project management methodologies began to bring better organization and control to bear on the process of delivering working software; we might label them “advanced ad hoc.” The next era would build on this base.

^在狂野西部时代，优化计算机资源优先于优化人力资源。25与今天相比，计算机处理周期、核心内存和外部内存的成本是巨大的。硬件开始了摩尔定律²⁶性能改进的征程。早些年，计算能力相对于人员成本而言是昂贵的，这导致了一些妥协，其中一些妥协造成了多年的问题（例如 Y2K 问题）。今天，在一个深陷数字革命的世界里，情况已经逆转：与计算机资源相比，人员成本很高。

In the Wild West era, optimizing computer resources took precedence over optimizing people resources.²⁵ The costs of computer processing cycles, core memory, and external memory were enormous compared to those today. Hardware began its Moore’s law²⁶ performance improvement march. In early years, computing power was expensive compared to personnel costs, which led to compromises, some of which caused problems for years (such as the Y2K issue). Today, in a world mired in the digital revolution, the situation has reversed: People costs are high compared to computer resources.

25.感谢我的《EDGE》一书的合著者 David Robinson 提出这一概念。

25. Thanks to David Robinson, my EDGE book co-author, for this concept.

26. 1965年，英特尔联合创始人戈登·摩尔观察到了后来被称为摩尔定律的现象：“集成电路中晶体管的数量大约每两年翻一番。”

26. In 1965, Gordon Moore, the co-founder of Intel, observed what became known as Moore’s law: “The number of transistors in an integrated circuit doubles about every two years.”

尽管在狂野西部时代软件开发尚处于起步阶段，但还是提供了有价值的解决方案。其中一些系统经过反复修改，至今仍然存在。以今天的标准来看，这些系统还很原始，但它们确实有效。

Although software development was in its infancy in the Wild West era, valuable solutions were delivered. Some of these systems, modified repeatedly, still exist today. Systems were primitive by today’s standards, but they worked.

時代總觀

Era overview

结构化时代包括三个阶段，这三个阶段有相当大的重叠。方法阶段让许多参与者参与了结构化革命。在巨型方法阶段，结构化方法与项目管理实践相结合，形成包含开发阶段、详细任务和文档要求的软件生命周期管理方法。随着这些方法发展成为巨型方法，下一个发展当然是自动化图形图表和必要的文档。最后一个阶段被称为计算机辅助软件工程 (CASE) 工具阶段。

The Structured era consisted of three phases, which overlapped considerably. The Methods phase brought a number of entrants into the structured revolution. In the Monumental Methodologies phase, structured methods were integrated with project management practices into software life-cycle management methodologies containing development phases, detailed tasks, and documentation requirements. As these Methodologies grew into Monumental ones, the next evolution was, of course, to automate the graphics diagrams and the requisite documentation. This last phase was dubbed the Computer-Aided Software Engineering (CASE) Tools phase.

本章描述了这三个阶段，并给出了结构化方法的示例、几个客户故事、技术和管理进步的概述，以及对一个概念——瀑布生命周期——的深入研究，该概念在接下来的几十年里主导了人们的思维。

These three phases are described in this chapter together with examples of structured methods, several customer stories, a glimpse at technology and management advances, and an in-depth look at a concept—the waterfall life cycle—which was to dominate thinking for the next couple of decades.

20 世纪 80 年代初，世界正努力应对高通胀和经济衰退、伊朗人质危机以及政治转向保守主义，因为自由派花生种植者吉米·卡特让位于共和党好莱坞演员罗纳德·里根担任美国总统。电影《夺宝奇兵》让观众惊叹不已，但奥斯卡评委却不以为然。20 世纪 80 年代末，柏林墙倒塌，麦当娜人气飙升。新的计算机技术出现，大片和 MTV 重塑了流行文化。这是一个变革的时代，但变革速度仍然很温和——仍然处于 Cynefin 复杂阶段，良好实践占主导地位，逐渐进入复杂阶段，需要一套不同的实践。

The wider world during the early 1980s was grappling with high inflation and a recession, the Iran hostage crisis, and a political shift toward conservatism as liberal peanut farmer Jimmy Carter gave way to Republican Hollywood actor Ronald Reagan as U.S. president. The movie Raiders of the Lost Ark wowed the public, but not the Oscars voters. The later 1980s saw the Berlin Wall fall and the rising popularity of Madonna. New computer technologies emerged and blockbuster movies and MTV reshaped pop culture. It was a time of change, but the rate of change was still moderate—still in the Cynefin complicated phase, where good practices dominated, edging into the complex phase, which required a different set of practices.

20 世纪 80 年代初，我在俄勒冈州波特兰工作时遇到了杰瑞·戈登，他带我去华盛顿州亚当斯山的山坡上爬山。此后，除了工作之外，我每年夏天都会花几周时间去华盛顿州的喀斯喀特山脉登山和攀岩。

Working in the early 1980s in Portland, Oregon, I met Jerry Gordon, who introduced me to mountain climbing on the slopes of Mt. Adams in Washington. After that, in addition to working, I spent a couple of weeks every summer mountaineering and rock climbing in Washington’s Cascade Mountains.

软件方法

Software methods

2011 年，Netscape 联合创始人马克·安德森在《华尔街日报》上发表了一篇题为《软件为何正在吞噬世界》的文章。软件可能正在吞噬世界，但它也可能肆虐世界。

In 2011, Marc Andreesen, cofounder of Netscape, authored an article in The Wall Street Journal titled “Why Software Is Eating the World.” Software may be eating the world, but it can run amok as well.

软件开发人员和软件开发需要不断发展，以应对快速发展、复杂世界的挑战。我们需要让软件更有价值、更安全。软件工程师努力追求合法性，消除失败是结构化时代的目标之一。

Software developers and software development needed to evolve to meet the challenges of our faster-moving, complex world. We needed to make software both more valuable and safer. Software engineers strived for legitimacy, and eliminating debacles was one goal of the Structured era.

需求、设计和编程的结构化方法建立在 20 世纪 70 年代的热情之上。进入 20 世纪 80 年代，结构化开发咨询和培训领域的领先公司是 Yourdon, Inc.，该公司成立于 1974 年。Ed Yourdon、Steve McMenamin、Tom DeMarco 和 Tim Lister 都是曾在 Yourdon 工作的软件开发先驱，我很荣幸多年来与他们成为朋友。

Structured methods for requirements, design, and programming built on the enthusiasm of the 1970s. As the 1980s got under way, the leading company in structured development consulting and training was Yourdon, Inc., founded in 1974. Ed Yourdon, Steve McMenamin, Tom DeMarco, and Tim Lister were all software development pioneers who worked at Yourdon, and with whom I was privileged to be friends over the years.

结构化方法包括一系列图表和方法，它们将规则和技术引入软件开发。图表是一种图形方式，用于描述组织中发生的流程：订单处理、库存控制、会计。图表是一种记录人们关于可以自动化什么的想法的方式。这些方法概述了一系列分析图表和文档，旨在从自动化业务功能的需求引导到物理实现的系统。

Structured methods comprised a series of diagrams and methods that together brought both discipline and techniques to software development. The diagrams were a graphic way of depicting processes that occurred in organizations: order processing, inventory control, accounting. The diagrams were a way to document one’s thinking about what could be automated. The methods outlined a series of analytical diagrams and documents designed to lead from the need to automate a business function to a physically implemented system.

DeMarco (1978) 的需求分析方法⁴使用数据流图 (DFD) 概述了四个阶段，如图 3.1所示：

DeMarco’s (1978) method for requirements analysis⁴ outlined four phases using data flow diagrams (DFD), as shown in Figure 3.1:

1. 分析当前物理业务流程流程。

2. Analyze the current physical business process flow.

3. 将当前物理流转换为当前逻辑流。

4. Convert the current physical flow to a current logical flow.

5. 检查当前的逻辑流程，提出改进的业务流程，并创建未来的逻辑流程。

6. Examine the current logical flow, propose an improved business flow, and create a future logical flow.

7. 创建未来的物理模型。

8. Create a future physical model.

4. Tom 的书和 Yourdon 的研讨会让我了解了结构化方法和方法论。我仍然保留着 1978 年的原版。

4. Tom’s book, and a Yourdon workshop, provided my introduction to structured methods and methodologies. I still have my original 1978 copy of the book.

结构化分析的第一步是通过采访系统用户，使用 DFD 记录“原样”业务流程。分析师的笔记可能像这样：“应付账款部门的 John 收到发票，确保供应商有账户，分配账号，复印一份，并将原件发送给付款组。”分析师将勾勒出流程，然后尝试简化流程，并根据需要修改图表。使用逻辑图、决策树或流程图记录逻辑和计算（例如计算付款金额）。DFD 包括气泡；气泡之间的箭头（表示流程）和数据存储。

The initial step in structured analysis was to document the “as is” business process using DFD by interviewing the system user. The analyst’s notes might read something like this: “John in accounts payable receives invoices, makes sure the vendor has an account, assigns account number, makes a copy, and sends the original to the payment group.” The analyst would sketch out the flow and then try to streamline the process, revising the diagrams as appropriate. The logic and calculations—calculating pay amount, for example—were documented using a logic diagram, decision tree, or flowchart. DFD included bubbles; arrows between bubbles, indicating flow; and data stores.

数据存储被描绘成开口的窄矩形框。当分析师审查发票时，他们会记下数据字段并将其分配给数据存储。当物理 DFD 被分析并转换为逻辑 DFD 时，分析师将创建一个新的逻辑 DFD，可能会添加新的流程和数据来改进手动系统。最后一步决定了新逻辑 DFD 的哪些部分将被自动化。当时，企业正在大力投资实现会计、订单处理和库存控制等内部业务功能的自动化。

The data stores were depicted as open-ended, narrow, rectangular boxes. As the analyst reviewed invoices, they would jot down the data fields and assign them to the data store. When the physical DFD had been analyzed and transformed into a logical DFD, the analyst would then create a new logical DFD, potentially adding new processes and data that improved on the manual system. The final process step determined which parts of the new logical DFD would be automated. At the time, businesses were heavily investing in automating internal business functions such as accounting, order processing, and inventory control.

最后，所有信息都会被收集到一个规范包中。虽然从物理到逻辑再到物理的转变似乎工作量很大，但这确实是一个需要经历的思考过程。我通常只处理一个 DFD，并根据每个阶段的需要对其进行修改。其他人会过于拘泥于流程，最终得到一堆 DFD。Ken Orr 曾经拜访过一个客户项目团队，他们向他展示了贴满 DFD 的会议室墙壁。“你怎么看？”他们问 Ken。“我认为你迷路了，”他回答道。

Finally, all the information would be gathered into a specification package. While this transition from physical to logical to physical might seem like excessive work, it was really a thought process to go through. I usually worked on a single DFD, modifying it as appropriate for each phase. Others would take the process too literally and end up with a morass of DFDs. Ken Orr once visited a customer project team who showed him conference room walls covered with DFD. “What do you think?” they asked Ken. “I think you are lost,” he replied.

在浏览 DeMarco 1978 年出版的结构化分析书时，我被其中这段话的“敏捷本质”所震撼：

In browsing through DeMarco’s 1978 structured analysis book, I was struck by the “agile nature” of this passage:

人类的大脑是一个迭代处理器。它从不会第一次就把事情做得完全正确。它特别擅长对不完美的任务进行改进。它可以一遍又一遍地这样做，每次都能得到更好的结果。（第 79 页）

The human mind is an iterative processor. It never does anything exactly right the first time. It is particularly good at taking an imperfect implementation of a given task and making improvements to it. This it can do over and over again, coming up with better results each time. (p. 79)

汤姆的引言早期就表明，迭代开发可能比规定性的串行开发更可取。

Tom’s quote was an early indication that iterative development might be preferrable to prescriptive, serial development.

这项早期工作是在数据库管理系统 (DBMS) 和随机存取磁盘存储广泛使用之前进行的。随着它们的使用增加，最初由 Peter Chen 开发的实体关系 (ER) 图（图 3.2）被用于对数据库需求进行建模。请记住，在此期间，企业正在大力投资实现会计、订单处理和库存控制等内部业务功能的自动化。

This early work occurred before the wide use of database management systems (DBMS) and random-access disk storage. As their use increased, entity-relationship (ER) diagrams (Figure 3.2), developed originally by Peter Chen, were used to model database requirements. Remember, during this time frame, businesses were heavily investing in automating internal business functions like accounting, order processing, and inventory control.

在此过程中，有一些愚蠢的方法争论。例如，分析师应该在 DFD 上使用圆形还是矩形气泡？各种结构化方法之间也存在不同的观点。从名称中可以看出，DFD 首先关注业务流程流。DFD 将流程步骤显示为圆形，将数据存储显示为矩形，但优先级是流程。Ken Orr 的 DSSD 以不同的方式进行分析，重点关注首先是期望的系统输出，然后才是生成这些输出的流程。

Along the way, there were silly method arguments. For example, should analysts use circular or rectangular bubbles on DFD? There were also differences in perspectives among the various structured methods. As you can assume from the name, DFD focus on the business process flow first. DFD show flow steps as circles and data stores as rectangles, but the priority is flow. Ken Orr’s DSSD approached analysis differently by focusing on the desired system outputs first, and only then the process flow to generate those outputs.

系统图和程序图都与图 3.3类似。许多图表用于逻辑，包括像图 3.4所示的 Warnier-Orr 图。

Both system charts and program charts are similar to the one in Figure 3.3. Many diagrams were used for logic, including Warnier-Orr diagrams like the one shown in Figure 3.4.

产出优先 (Orr) 还是流程优先 (Yourdon)？最终两者都需要，尽管我更喜欢产出驱动的分析。在 20 世纪 80 年代，我曾开过讲习班，并就各种方法提供咨询。它们之间的相似之处比不同之处要多，就像今天的敏捷方法一样。

Output first (Orr) or process first (Yourdon)? In the end you needed both, although the output-driven analysis appealed more to me. During the 1980s, I taught workshops and consulted on a variety of methodologies. There were many more similarities than differences, as with agile methodologies today.

这些结构化方法仍然需要从需求到设计、从设计到代码的繁琐转换。程序员并不总是精通如何使用图表。分析师和设计师常常认为转换是显而易见的。早些年，关于这个问题的争论很平淡，因为所有角色都是由单个人实例化的。后来，随着瀑布式生命周期、更大的项目和孤立的开发团队的发展，这些差距变得更加麻烦。

These structured approaches still required a laborious translation from requirements to design, and from design to code. Programmers were not always well versed in how to use the diagrams. Analysts and designers often thought the transformations were obvious. In the early years, the debate over this issue was muted because all the roles were instantiated in single individuals. Later, with the movement to waterfall life cycles, larger projects, and siloed development groups, these gaps proved more troublesome.

软件开发人员正在研究一种通过终端与用户交互的新方式，并学习使用随机磁盘访问进行事务处理。从批量更新到串行磁带文件，现在他们可以执行近乎即时的单笔交易更新。在为这种新的交易环境重新设计系统时，我合作过的一家组织有一个会计系统备份程序，该程序使用了前一天午夜的主文件，因此工作人员必须重新输入自那时以来创建的所有交易数据。显然，会计人员不太喜欢这个程序。

Software developers were dealing with a new way of interacting with users via terminals and learning transaction processing with random disk access. Going from batch updates to serial tape files, now they could perform near-instantaneous single transaction updates. When redesigning its systems for this new transactional environment, an organization I worked with had an accounting system backup procedure that used the primary file from the previous midnight, so staff had to reenter all the transaction data that had been created since then. Obviously, the accounting staff didn’t like this procedure much.

方法、方法论和思维方式

Methods, methodologies, and mindsets

您是否遇到过“方法”和“方法论”这两个词的模糊性问题？坦率地说，我可能曾一两次造成这种模糊性。在科学研究中，研究人员的方法论（策略）和收集数据的步骤（方法）通常在过程和随后发表的论文中很早就被定义。

Have you encountered fuzziness around the words method and methodology? To be candid, I have probably contributed to the fuzziness a time or three. In scientific research, the researcher’s methodology—the strategy—and steps to collect data—the methods—are often defined early in both the process and the subsequent published paper.

软件方法定义了交付由您选择的方法确定的工件的详细步骤。重构是一种提高代码质量的技术。您可以在方法论中有一个高级流程，称为“审查您的代码并进行改进”。那么重构可能是完成该过程的一种技术或方法。

A software method defines the detailed steps to deliver artifacts identified by your chosen methodology. Refactoring is a technique for improving the quality of code. You could have a high-level process in a methodology called “Review your code and make improvements.” Refactoring might then be one technique or method to accomplish that process.

软件方法论定义了您的策略。它将软件工作分为活动或步骤，每个步骤可能包括特定可交付成果（需求文档）和工件（DFD）的定义。软件开发生命周期 (SDLC) 定义了最高级别的流程序列，这些流程具有瀑布、螺旋和迭代等名称。

A software methodology defines your strategy. It divides software work into activities or steps, each of which may include the definition of specific deliverables (a requirements document) and artifacts (DFD). Software development life cycles (SDLC) define the highest-level sequence of processes, which bear names like waterfall, spiral, and iterative.

分界线处容易产生混淆。例如，极限编程包含 12 种实践，包括简单设计、测试和重构。由于重构有多种方式，那么它是方法还是方法论？科学家在研究早期就定义了这些术语，所以我也会这样做：在本书中，当方法论涵盖多个开发阶段时，我将使用方法论这个术语。传统的例子是 Method/1、STRADIS 和 DSSD；敏捷的例子是 Scrum、极限编程和 Crystal。5^方法 可能包括 DFD 、重构或数据建模。

Confusion arises at the dividing line. For example, Extreme Programming comprises 12 practices including simple design, testing, and refactoring. Since there are several ways to go about refactoring, is it a method or a methodology? Scientists define these terms early in their research, so I will do the same: In this book, I will use the term methodology when it covers several development phases. Traditional examples would be Method/1, STRADIS, and DSSD; agile examples would be Scrum, Extreme Programming, and Crystal.⁵ Methods might then include DFD, refactoring, or data modeling.

5.所有这些方法都将在本书后面进行解释。

5. All of these methodologies are explained later in the book.

心态是一种态度，是一套我们用来理解世界的信念。心态让我们从某个角度思考问题，对事件产生感受，并采取相应的行动。在软件开发中，谨慎心态的人对事件的解读与冒险心态的人不同。

A mindset is an attitude, a set of beliefs we use in making sense of the world. Our mindsets cause us to think about issues from a certain perspective, to have feelings about events, and to act accordingly. In software development, a person with a cautious mindset will interpret an event differently from a person with an adventurous mindset.

当我们回顾软件开发的演变和变革时，我们需要记住，方法、方法论和思维方式都是为了解决每个时代的问题而发展起来的，它们既受到当时技术的支持，也受到当时技术的制约。根据我的经验，我看到每种方法都成功过，也看到每种方法都失败过。

As we traverse the evolution and revolution of software development, we need to remember that methods, methodologies, and mindsets all evolved to solve the problems of each era, and were both enabled and constrained by the technology of that time. In my experience, I’ve seen every methodology succeed, and also every one fail.

CSE/电信公司

CSE/Telco

我的两项合作，一项是与芝加哥证券交易所 (CSE) 的合作，另一项是与佛罗里达州的一家电信公司 (telco) 的合作，说明了结构化时代遇到的软件开发问题。

Two of my engagements, the first with a Chicago Stock Exchange (CSE) and the second with a telecommunications company (telco) in Florida, illustrate software development issues encountered during the Structured era.

20 世纪 80 年代中期，我经常去芝加哥的一家证券交易所担任顾问，为我的客户提供 DSSD 方面的建议。除了与软件开发小组密切合作外，我还时不时地去企业数据库小组。企业数据库小组的经理抱怨开发小组不支持他创建企业数据模型（太不切实际），而 IT 副总裁通常站在开发经理一边。数据经理和他的员工非常沮丧，他们浪费时间构建自定义数据字典，而不是购买现成的应用程序。有几次，我与数据经理坐下来分享了我的观察结果。

In the mid-1980s, I frequently traveled to Chicago to consult at a stock exchange, advising my client on DSSD. In addition to working closely with the software development group, I wandered over to the enterprise database group from time to time. The manager of the latter group complained when the development group would not support his creation of an enterprise data model (too pie in the sky), and the IT vice president usually sided with the development manager. The data manager and his staff grew so frustrated that they wasted time building a customized data dictionary rather than purchasing a readily available application. On several occasions, I sat down with the data manager and shared my observations.

“您的团队在开发经理眼中毫无信誉。您一直在推广这个复杂的企业数据模型，但开发经理却面临着今天交付系统的压力。我建议您为开发团队当前的项目提供数据设计帮助，以建立信誉。您的员工将获得信誉，并了解系统级数据，这些数据可能对更高级别的数据模型有用。”

“Your group has no credibility with the dev manager. You keep pushing this elaborate corporate data model, but the dev manager is under pressure to deliver systems today. I suggest you offer data design assistance to dev teams on their current projects to build credibility. Your staff would gain both credibility and understanding of system-level data that could be useful in higher-level data models.”

当然，他的骄傲、自负和自以为是的心态不允许数据经理听从我的建议。最终，他沮丧地离开了组织。软件开发和数据组织之间的这种分裂将持续多年，并以多种方式表现出来。

Of course, his pride, ego, and sense he was “right” wouldn’t let the data manager take my advice. Eventually he left the organization in frustration. This schism between software development and data organizations would continue for years to come, presenting itself in numerous ways.

我在交易所工作期间发现的一个趣闻是使用 Warnier-Orr 图来建模逻辑，而不是更广泛使用的结构图或流程图。当从经纪人那里收到订单时，路由这些订单的算法非常复杂，需要 17 页 Warnier-Orr 图。它们是高效、直观且出色的图表，适合与用户协作。

One tidbit from my time working at the exchange was the use of Warnier-Orr diagrams to model logic, rather than the more widely used structure charts or flowcharts. When orders were received from brokers, the algorithm for routing them was extremely complex, taking 17 pages of Warnier-Orr diagrams. They were efficient, visual, and excellent diagrams for collaboration with users.

还有一次，我在佛罗里达州坦帕市为一家电信公司开了一个研讨会。来自多个地区的代表正在设计一个通用的设备维护系统。整合的系统将供所有地点使用，但他们还需要能够生成本地相关报告。他们在设计时首先问自己：“我们需要哪些数据实体和属性？”，然后使用实体关系图对结果进行建模。

ON ANOTHER OCCASION, I taught a workshop for a telco in Tampa, Florida. Representatives from multiple districts were designing a common equipment maintenance system. The consolidated system was to be used by all locations, but they also needed the ability to generate locally relevant reports. They had approached the design by first asking themselves, “What data entities and attributes do we need?” and then modeled the results using entity-relationship diagrams.

我问学员们：“你认为所有的报告都能够从这个数据模型结构生成吗？”

I asked the participants, “Do you think all the reports can be generated from this data model structure?”

“当然。”他回答道。

“Of course,” was the reply.

我让他们分成地区小组，每个小组针对他们所在的地区列出几份高优先级报告。然后他们确定是否可以从他们的数据模型生成 18 份左右的报告。成功报告的总数为零。虽然我曾假设会存在一些脱节，但结果让我感到惊讶，他们大多感到震惊。从输出到数据库再到输入的逆向设计是有好处的。

I had them organize into district groups and had each group lay out several high-priority reports for their location. They then determined whether the 18 or so reports could be generated from their data model. The total number of successful reports: ZERO. While I had assumed there would be some disconnect, I was surprised at the result, and they were mostly in shock. There were benefits to designing backward from outputs to database to inputs.

结构化先驱

Structured pioneers

如果您搜索关键词“软件先驱”，搜索结果无疑会偏向于我所说的工程应用：算法、语言、操作系统和实时控制系统。经常提到的名字包括 EW Diijkstra、Niklaus Wirth 和海军上将 Grace Hopper。对比商业系统和工程系统，我认为具有开创性的人和工作包括 Ed Yourdon 的《在线计算机系统设计》（1972 年）；Tom DeMarco 的《结构化分析和系统规范》（1978 年）；Chris Gane 和 Trish Sarson 的《结构化系统分析：工具和技术》（1980 年）；Ken Orr 的《结构化需求定义》（1981 年）；Larry Constantine 的《结构化设计》（与 Ed Yourdon 合著，1975 年）；以及 Steve McMenamin ⁶和 John Palmer 的《基本系统分析》（1984 年）。这可能过于简单化，但技术或工程先驱构建了工具，商业先驱应用这些工具来分析、设计、编程和测试业务系统。

If you perform a search for the key phrase “software pioneers,” the results will undoubtedly be skewed toward what I’ll call engineering applications: algorithms, languages, operating systems, and real-time control systems. Names such as E. W. Diijkstra, Niklaus Wirth, and Admiral Grace Hopper are frequently mentioned. Contrasting business systems with engineering systems, people and work I consider pioneering include Ed Yourdon, Design of On-Line Computer Systems (1972); Tom DeMarco, Structured Analysis and System Specification (1978); Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and Techniques (1980); Ken Orr, Structured Requirements Definition (1981); Larry Constantine, Structured Design (with Ed Yourdon, 1975); and Steve McMenamin⁶ and John Palmer, Essential Systems Analysis (1984). It may be an oversimplification, but the technical or engineering pioneers built the tools, and the business pioneers applied those tools to analyze, design, program, and test business systems.

6.我正式接触“结构化”是在 Steve McMenamin 教授的 Yourdon 分析课上。

6. My formal introduction to “structured” was a Yourdon analysis class taught by Steve McMenamin.

汤姆·德马科是结构化方法时代的主要贡献者，是发展中人本主义的早期倡导者，也是一位深思熟虑的声音在信息技术的发展中。你很少有机会与你的偶像成为朋友，就像我在 20 世纪 90 年代后期与汤姆成为朋友一样。汤姆改变了软件开发，首先是技术（DeMarco，1978 年），然后是人（DeMarco，1987 年）。他也是一位引人入胜的演讲者和富有洞察力的会议主持人。为了写这本书，我与汤姆有过几次电子邮件交流，向他提出了一系列问题。

TOM DEMARCO WAS a major contributor to the structured methods era, an early advocate for the people side of development, and a thoughtful voice in the evolution of information technology. You don’t often get to be friends with your heroes, as I did with Tom later in the 1990s. Tom changed software development, first with technology (DeMarco, 1978) and then with people (DeMarco, 1987). He was also both a captivating speaker and an insightful conference facilitator. I had several email exchanges with Tom for this book, posing a series of questions to him.

在 Yourdon 和您的《结构化分析》一书之前您参与过什么工作？

What were you involved with prior to Yourdon and your Structured Analysis book?

管理大型网上银行系统。我们听了 SofTech 的演示，其中展示了他们的数据流技术，他们的图形让我非常着迷，这是我以前从未见过的。

Managing a large online banking system. We had a presentation by SofTech that showed their data flow techniques, and I was taken with their graphics, which I hadn’t encountered before.

您的结构化想法是如何产生和发展的？

How did your structured ideas come about and evolve?

我的职业生涯始于贝尔实验室，当时我从事分布式实时系统的研究，这意味着数据流比控制流更能暗示系统要完成什么。我很早就明白了这一点，但当时还不太想开发图形来让这个想法更容易传达。

I started my career at Bell Labs working on a distributed real-time system that meant the flow of data gave a much stronger hint than the flow of control about what the system was trying to accomplish. I was early to understand that, but wasn’t yet inclined to develop graphics to make the idea communicable.

当时软件开发的状况如何？什么促进了结构化开发？

What was the state of software development then, and what encouraged structured development?

这样说似乎有些苛刻，但当时的软件开发完全是关于代码和调试的。没有真正的设计概念，尽管我们都知道有些人的代码比其他人的代码漂亮得多、更容易理解。有些人写的代码完全无法理解，所以我们很多人都在回头思考这个问题：你会怎么做才能让你的代码变得无法理解？我们想出了这样做的方法，以便创建一个禁忌列表。

This seems harsh to say, but software development at the time was all about code and debug. There was no real concept of design, though we were all aware that some people’s code was a lot prettier and more understandable than that of others. And there were some people who wrote code that was totally incomprehensible, so a lot of us were thinking backward about the problem: What would you do to MAKE your code incomprehensible? We were coming up with ways to do just that in order to create a list of no-nos.

^{我在贝尔实验室7}关注的一个领域与注释有关。我曾提出，如果代码中不允许注释，人们会倾向于编写更好的代码。8^因此，

One area of my focus at Bell Labs⁷ had to do with comments. I had proposed that if comments weren’t allowed in the code, people would be inclined to write better code.⁸ So instead of

7 . 贝尔电话实验室 (1925–1984) 是计算机早期创新的温床。贝尔实验室的研究人员因晶体管和激光的开发而受到赞誉。在计算机领域，他们开发了 Unix 操作系统和编程语言 C、C++、SNOBOL 等。贝尔实验室的工作曾九次获得诺贝尔奖。

7. Bell Telephone Laboratories (1925–1984) was a hotbed of innovation in the early years of computing. Bell Lab researchers are credited with the development of the transistor and the laser. In the computing realm, they developed the Unix operating system and the programming languages C, C++, SNOBOL, and others. Nine Nobel Prizes have been awarded for work at Bell Labs.

8.几十年后，肯特·贝克在他的极限编程著作中提倡编写可读性强的代码，并删除大部分注释。软件开发中一代又一代涌现出一些好的想法。不幸的是，坏想法种类繁多。

8. Kent Beck would advocate for writing readable code and eliminating most comments in his Extreme Programming work decades later. There are a few good ideas in software development that arise generation after generation. Unfortunately, there happens to be a greater variety of bad ideas.

单击此处查看代码图像

Click here to view code image

ADT turnip，1 * 增加中继矩阵索引

ADT turnip, 1 * increment the relay matrix index

你会（只是为了保持理智）自然而然地写下

you would (just to preserve your sanity) be naturally led to write

ADT 中继矩阵索引,1

ADT RelayMatrixIndex,1

现在看来很明显，但删除注释对我们的代码有很大的改进。“萝卜”示例来自我遇到的实际代码，其中所有数据名称都是蔬菜。

It seems obvious now, but getting rid of comments made a huge improvement in our code. The “turnip” example was from actual code I encountered in which all data names were vegetables.

这不可避免地导致了函数这一令人吃惊的新概念的出现。与需要大量解释的程序中间的长段不同，您可以定义一个具有高度描述性的名称并在代码主行中调用它的函数。这意味着主行可以轻松理解而无需注释。在此之前，函数仅用于描述可能重复使用的代码；我们反而使用它们使例程的顶层更易于理解。

This led inevitably to a startlingly new concept of functions. In place of a long section in the middle of a program that would need a lot of explanation, you could define a function with a highly descriptive name and call it in the main line of code. That meant the main line could be easily understood without comments. Prior to that, functions were used only to describe code that might be reused; we instead used them to make top levels of routines more comprehensible.

谁对你有影响？

Who were your influencers?

我的主要影响者是 Ed Yourdon。在 Ed 成立 Yourdon, Inc. 之前，我们曾在 Mandate Systems 共事多年。正是 Ed 让我想到了“图片规范”的想法，因为他热衷于描绘任何可以保持静止的东西。为什么不制定规范呢？

My main influencer was Ed Yourdon. We had worked together at Mandate Systems years before Ed formed Yourdon, Inc. And it was Ed who got me thinking of the idea of a “picture specification,” since he was into picturing anything that would hold still for it. Why not the specification?

您认为结构化开发的主要优势是什么？

What did you observe as the major benefits of structured development?

从左脑思维到右脑思维的转变。当时我们都被朱利安·杰恩的书《双脑思维的崩溃中的意识起源》迷住了。（同样，是埃德·尤顿首先把这本书交到我手中。）我们从中得到的主要想法是，用左脑方法解决本质上是多维的问题，这是我们当时软件开发方法的悲剧性缺陷。

The shift from left-brain thinking to right-brain thinking. We were all enchanted at the time by Julian Jayne’s book, The Origin of Consciousness in the Breakdown of the Bicameral Mind. (Again, it was Ed Yourdon who first put that book into my hands.) The major idea we took from it was using left-brain methods for an inherently multidimensional problem was the tragic flaw of our then approach to software development.

人们/组织是如何滥用结构化技术的？

How did people/organizations misuse structured techniques?

有些系统是数据流密集型的，而有些系统是数据结构密集型的。我的意思是，有些系统最适合通过关注数据项本身在传输过程中的视图来描述，而有些系统则最好通过关注数据项之间的关系来描述。典型的数据库系统有流入和流出存储库的数据，这并不能说明什么。另一方面，分布式和实时系统的数据结构很少，但数据流很多。将数据流方法应用于在我看来，数据库系统是一种滥用。数据库设计的巨大进步几乎与结构化方法的成熟同时发生。许多人选择他们的方法（无论是其中一种）时，很少考虑所选方法对他们的特定系统的效果如何。

Some systems are data flow intensive, and others are data structure intensive. I mean some systems are most appropriately described by calling attention to the view of the data items themselves as they make their way through, while others are better described by calling attention to the relationships among data items. A typical database system has flows into and out of the repository, which doesn’t tell you much. Distributed and real-time systems, on the other hand, have little data structure but lots of flow. Applying data flow methods to a database system is, in my opinion, a misuse. The great strides forward in database design were happening almost at the same time as structured methods were coming of age. And lots of people chose their methods—either one or the other—with little regard to how well the chosen method worked for their particular system.

对结构化时代（大约 1980 年代）有什么一般性观察吗？

Any general observations from the Structured era, roughly the 1980s?

奇怪的是，这是技术写作的复兴。软件行业每年的收入已突破 100 亿美元大关，但几乎没有任何关于工作应该如何进行的记录。（六十年代的典型书籍是像 Daniel McCracken 写的编程书籍，大部分只是对语言指令集的解释。）突然间，有了一些可以从中获取见解的书籍。同样，Ed Yourdon 是这一趋势的早期代表。Ed 的写作速度与打字速度一样快，他是我见过的打字速度最快的人。我们有时共用一个办公室，当他开始打字时，就像坐在机关枪旁边一样。他写出的文字可读性很高，常常很有趣，而且充满洞察力。他为我们其他人树立了标准。

It was, oddly enough, a renaissance for technical writing. The software industry had moved through the $10 billion a year mark with almost nothing written down about how the work ought to proceed. (Typical of the sixties were programming books like the ones written by Daniel McCracken, mostly just explanations of language instruction sets.) Suddenly, there were books you could go to for insight. Again, Ed Yourdon was early in this trend. Ed wrote at typing speed, and he was the fastest typist I ever encountered. We shared an office at times and when he started typing, it was like sitting next to a machine gun. And the text he turned out was highly readable, often amusing, and full of insight. He set a standard for the rest of us.

是什么影响了您将重点从技术实践转变为您在《人件》（DeMarco 和 Lister，1987）和Slack（DeMarco，2001）中所写的人员实践？

What influenced your change in emphasis from technical practices to the people practices you wrote about in Peopleware (DeMarco and Lister, 1987) and Slack (DeMarco, 2001)?

在与 Tim Lister 一起飞往澳大利亚悉尼的航班上，我们一起合作开展了第一次 Peopleware 会议。我们当时正在座位上画 OHP（高架投影仪）幻灯片。我们中的一个人观察到——我们都不记得是谁第一次说出这句话——软件开发的主要问题更多是社会问题而非技术问题。这成为了我们的口头禅，在接下来的几年里，我们一起唱着“共和国战歌”。我认为这句话今天和当时一样正确，只是我现在认为它的适用范围要广泛得多，涉及的主题比软件更广泛。

On a flight to Sydney, Australia, with Tim Lister, we were working together on our first Peopleware session. We were actually drawing OHP (overhead projector) slides at our seats. One of us observed—neither of us remembers who said the words for the first time—that the major problems of software development are more sociological than technological. That became our mantra, our “Battle Hymn of the Republic” we sang together for the next few years. It’s something I think is every bit as true today as it was then, only I now think it applies much more broadly, to subjects more diverse than just software.

Slack源于类似的观察，即组织的规则基础被允许发展而不是被设计，而它们的发展往往会导致它们陷入有吸引力但具有破坏性的死胡同，例如加班、倦怠、不可能的最后期限、死亡行军项目和规定性方法。

Slack stemmed from a similar observation, that the rule bases of organizations had been allowed to evolve instead of being designed, and their evolution tended to lead them into appealing but destructive dead ends like overtime, burnout, impossible deadlines, death march projects, and prescriptive methodology.

这两部作品都有一个共同的主题：不妨碍别人可以带来巨大的进步。

Both works have a common theme: Getting out of people’s way can be a recipe for huge improvement.

拉里·康斯坦丁首创了至今仍在使用的耦合和内聚的基本设计概念。但他的履历远不止这些成就。从麻省理工学院 (MIT) 获得管理学学位后，拉里在该校核研究所担任程序员。他成为塔夫茨大学精神病学临床助理教授，并在 20 世纪 80 年代中期撰写了一本关于家庭治疗的书。他以笔名 Lior Samson 出版了 16 部小说。我对拉里不像同时代的其他先驱那样了解，但他对我的职业生涯产生了一些影响，我将在后面的章节中描述。​​我在电子邮件交流中向拉里提出了一系列问题。

LARRY CONSTANTINE ORIGINATED the fundamental design concepts of coupling and cohesion still in use today. But his resume goes far beyond that achievement. Upon graduating from Massachusetts Institute of Technology (MIT) with a management degree, Larry worked as a programmer in its Nuclear Research Institute. He became an assistant clinical professor of psychiatry at Tufts University and wrote a book on family therapy in the mid-1980s. Under the pen name Lior Samson, he has published 16 fiction titles. I didn’t know Larry as well as other pioneers of the times, but he had several impacts on my career, as I will describe in later chapters. I posed a series of questions to Larry in an email exchange.

您早期的职业是什么样的？它如何影响您后来的结构化思想？

What was your early career and how did it result in your later structured ideas?

1963 年，我开始研究这些想法，当时我在麻省理工学院核科学实验室从事第一份全职编程工作，当时我在 Harry Rudloe 手下工作，他对预先计划好的子程序编程有一种严谨但不正式的方法。真正的核心来自 1963 年晚些时候在华盛顿特区 CEIR, Inc. 的工作，在那里，耦合和内聚的概念在午餐时间与 Ken MacKenzie、Dave Jasper、Bud Vitoff 等人的闲聊中发展起来。后来，在我 1965 年回到麻省理工学院后，我才开始使用图表进行建模，并在 1966 年我创办第一家公司信息与系统研究所后迅速发展。

I started working on these ideas in 1963 at my first full-time programming job at the MIT Laboratory for Nuclear Science, where I worked under Harry Rudloe, who had a disciplined but nonformal approach to programming in preplanned subroutines. The real core arose from working at C-E-I-R, Inc., in D.C. later in 1963, where the concepts of coupling and cohesion evolved in lunchtime bull sessions with Ken MacKenzie, Dave Jasper, Bud Vitoff, and others. Modeling with diagrams came later, after my return to MIT in 1965, and evolved rapidly once I launched my first company, Information & Systems Institute, in 1966.

到 1968 年我的公司赞助全国模块化编程研讨会时，结构化设计的核心（但不是品牌）已经基本完成——现在被认为是模块化编程的创始转折点。我的论文是第一篇发表的核心概念和理论的完整概述，但我已经写了好几年这些想法。1974 年发表在《IBM 系统杂志》上的文章当然发起了 IBM 坚持的品牌“运动”。

The core of structured design (but not the branding) was more or less complete by the time my firm sponsored the National Symposium on Modular Programming in 1968—now recognized as a founding pivot point in modular programming. My paper was the first published complete outline of the core concepts and theory, but I had been writing about the ideas for several years. The IBM Systems Journal piece in 1974 of course launched the “movement” with branding insisted on by IBM.

当时软件开发的状况如何，为什么鼓励结构化开发？

What was the state of software development then, and why did that encourage structured development?

人们削减代码。差不多。有些人会将复杂的算法流程图化，有些人会进行某种形式的系统级流程图，但大多数人认为这是浪费时间。没有 CASE 工具，只有 IBM 塑料制图模板 [参见图 3.5中的示例]。在开始编程之前规划系统结构的想法一直存在，但是很少实践。

People cut code. Pretty much. Some would flowchart tricky algorithms, some would do some form of system-level process flow, but most considered that a waste of time. There were no CASE tools, only IBM plastic charting templates [see the example in Figure 3.5]. The idea of mapping out the structure of a system before starting to program was around, but little practiced.

9 . www.si.edu/object/ibm-gx20-8020-1-um010-flowcharting-template%3Anmah_694227。

9. www.si.edu/object/ibm-gx20-8020-1-um010-flowcharting-template%3Anmah_694227.

谁影响了你的想法？

Who influenced your thinking?

除了 CEIR 的三驾马车之外，我还得提一下詹姆斯·埃默里，他在我毕业于麻省理工学院之前就让我在沃顿商学院任教。在麻省理工学院，我沉浸在系统思维中——因此我读到了该领域的所有经典作家，包括后来的杰里·温伯格。埃德·尤顿在传播这些思想方面发挥了巨大作用，如果没有他的创业奇才和与我的合著，这些思想可能永远不会面世。他很聪明，也是一位很好的朋友。

Besides the troika at C-E-I-R, I would have to mention James Emory, who also got me teaching at the Wharton School before I even graduated from MIT. At MIT, I had been immersed in systems thinking—so all of the classic writers in that area, including Jerry Weinberg later. Ed Yourdon played a huge role in the propagation of the ideas, and they might never have seen the light of day were it not for his entrepreneurial wizardry and co-authoring with me. He was brilliant and a great friend.

结构化开发有哪些好处？

What were the benefits of structured development?

所有这些都被讨论过很多次了。在你知道代码是如何组织的之前，你怎么能编写代码呢？最大的贡献其实在于底层理论，这已经在数百项研究中得到了证实。耦合和内聚。这就是它的意义所在，而不是图表、流程或实践。保持组件紧密、紧凑和独立；弄清楚如何正确连接它们；构建。敏捷、RAD、OO [面向对象]、功能——理论是一样的。

All that’s been hashed over so many times. How can you cut code until you know how it’s organized? The biggest contribution was actually in the underlying theory, which has been validated in hundreds of studies since. Coupling and cohesion. That’s what it’s about, not diagrams or process or practices. Keep component parts tight, compact, and independent; figure out how to connect them correctly; build. Agile, RAD, OO [object orientation], functional—the theory is the same.

人们和组织是如何滥用结构化技术的？

How did people and organizations misuse structured techniques?

整个“瀑布”风波都是一派胡言。Ed [Yourdon] 和我将该模型设想为一种“训练轮”，但它在管理方面大行其道，然后随着面向对象和敏捷的出现而成为攻击的稻草人。纠正一下，OO 和敏捷并不是从 SD（结构化开发）的失败中发展而来的。SD 没有失败；几十年来，它在无数大大小小的项目中取得了有记录的成功。一些组织陷入了图表的暴政，尤其是在 CASE 出现之后，但这些模型始终只是工具，是外化、改进和记录思维的方式。有趣的是，DFD 一直是长期的大赢家，并且仍然在世界各地教授和使用。

The whole “waterfall” brouhaha was a crock. Ed [Yourdon] and I conceived that model as a form of “training wheels” but it took off with management and then became the straw man to attack with the arrival of object orientation and agile. To correct the record, OO and agile did not evolve out of the failure of SD (structured development). SD did not fail; it was a documented success in countless projects, large and small, over the decades. Some organizations fell into a tyranny of diagrams, especially after the arrival of CASE, but the models were always intended to be just tools, ways to externalize, refine, and document thinking. Interestingly, DFDs have been the big long-term winner and are still taught and used all over the world.

我同意 Larry 的评价。结构化方法、RAD 和敏捷方法都成功地交付了软件应用程序，尤其是在它们那个时代。当这些方法被大型、正式的方法所取代时，问题就出现了。耦合和内聚以及 DFD 等一些想法至今仍在使用。

I agree with Larry’s assessment. Structured methods, RAD, and agile methods all successfully delivered software applications, especially in their time. It was when these methods became subsumed by large, formal methodologies that problems arose. Some ideas like coupling and cohesion and DFD are still in use today.

虽然结构化方法在 20 世纪 60 年代就已发展起来，但其流行度在 20 世纪 70 年代末和 80 年代才开始提升，正如敏捷的种子在 20 世纪 90 年代生根发芽，然后在 21 世纪蓬勃发展一样。从 Larry 的早期出版物中可以看出结构化方法的这种演变迹象^。10

While structured methods were developed in the 1960s, their popularity increased in the late 1970s and 1980s, just as the seeds of agile took root in the 1990s, then flourished in the 2000s. Indications of this evolution for structured methods can be seen from Larry’s early publications.¹⁰

10. Constantine，1967 年；Constantine，“模块化程序中的序列和并行控制”，1968 年；Constantine，“模块化编程的分段和设计策略”，1968 年；Constantine，“编程专业、编程理论和编程教育”，1968 年；Constantine，“整体硬件/软件设计”，1968-1969 年；Constantine 和 Donnelly，1967 年 10 月；Constantine、Stevens 和 Myers，1974 年；Constantine 和 Yourdon，1975 年。

10. Constantine, 1967; Constantine, “Control of Sequence and Parallelism in Modular Programs,” 1968; Constantine, “Segmentation and Design Strategies for Modular Programming,” 1968; Constantine, “The Programming Profession, Programming Theory, and Programming Education,” 1968; Constantine, “Integral Hardware/Software Design,” 1968–1969; Constantine and Donnelly, October 1967; Constantine, Stevens, and Myers, 1974; Constantine and Yourdon, 1975.

信息架构师有限公司

Information Architects, Inc.

两年半之后，我厌倦了每周通勤穿越半个国家，于是告诉 Ken Orr，我将继续以独立承包商的身份在研讨会上授课、为客户提供咨询，并担任 KOA 产品在东南部的销售代理。我在新成立的公司 Information Architects, Inc. 下从事其他工作。我们（一名员工和我）搬到了佐治亚理工学院的初创企业孵化中心，尝试以软件企业家的身份开发营销和销售应用程序。我从咨询工作中获得了初创企业的资金，但由于其他资金未能到位，我不得不放弃这一努力。

After 2½ years, tired of commuting halfway across the country each week, I told Ken Orr I would continue to teach workshops and consult with customers as an independent contractor and be a sales agent for KOA’s products in the Southeast. I pursued other work under my newly formed company, Information Architects, Inc. We—that is, one employee and me—moved into the Georgia Tech start-up incubation center, tempting the fates as a software entrepreneur with a marketing and sales application. I funded the start-up from my consulting work but had to abandon the endeavor when other funding failed to materialize.

我的咨询工作之一是审计亚特兰大一家保险公司的项目。这次审计的同事是一位前大公司 IT 经理。该公司的内部保险处理系统运行在霍尼韦尔的大型机上，需要进行重大升级。该公司拥有各种人寿和意外险产品以及一个独立销售代理网络。是时候进行重大改革了。

One of my consulting gigs was to audit a project for an insurance company in Atlanta. My cohort in this review was a former large company IT manager. The company’s internal insurance processing systems were running on a Honeywell mainframe and needed a serious upgrade. The company had a variety of life and casualty products and a network of independent sales agents. It was time for a major overhaul.

IBM 销售一套综合保险处理系统，因此决定将 IBM 软件转换为 Honeywell 硬件 — 这是一项重大任务。为了降低转换成本，IT 经理决定将转换后的软件出售给运行 Honeywell 计算机的其他公司。尽管该公司预售了（转换前）几个安装，但 90% 到 95% 的保险公司使用 IBM 硬件，因此转换后系统的潜在市场很小。我们的项目审查目标是建议该公司是否应该放弃该项目，并针对任何一种情况提出进一步的行动。

IBM sold a comprehensive insurance processing system, so the decision was made to convert the IBM software to Honeywell hardware—a major undertaking. To reduce the conversion costs, the IT manager decided to sell the converted software to other companies running Honeywell computers. Although the firm presold (before conversion) a couple of installations, 90% to 95% of insurance companies used IBM hardware, so the potential market for the converted system was tiny. Our project review objective was to recommend whether or not the company should abandon the project and to propose further action in either case.

经过数年时间和数百万美元的投入，他们却没有取得任何进展。测试不断进行。我开始与公司的首席执行官一起进行审查。

After several years and significant millions of dollars, progress had eluded them. Testing went on and on. I started the review with the CEO of the firm.

“你参与了什么？你如何监控进展？”我问道。

“What was your involvement and how are you monitoring progress?” I asked.

“好吧，”他回答道，“我批准了该项目的预算，顺便说一句，预算已经大大超出了，但我没有参与其他工作。你需要和我的产品线副总裁谈谈。”

Well,” he replied, “I approved the budget for the project, which has been greatly exceeded by the way, but I haven’t been involved otherwise. You need to talk with my product line VPs.”

于是，我采访了副总裁。你猜怎么着？他们也没有参与。他们建议我和经理谈谈，经理建议我和他们的主管谈谈。然后我继续向下层级采访，直到我采访了保险职员和程序员，他们并不真正了解无法实现项目目标，并感到沮丧。当时的典型情况是，用户希望修改系统以适应他们的流程，而不是采用软件包流程，因此开发团队陷入了修改的泥潭。当然，修改降低了软件包的好处，管理层对发生的事情一无所知。优先级由办事员和程序员设定。

So, I interviewed the vice presidents. And guess what? They hadn’t been involved, either. They suggested I speak with the managers, who suggested I talk with their supervisors. And down the hierarchy I went, until I was talking with insurance clerks and programmers who didn’t really understand the project’s goals and were frustrated. Typical of the time, the users wanted to modify the system to fit their processes, rather than adopting the package processes, so the dev team was bogged down with modifications. Of course, the modifications reduced the benefits of the packaged software, and the management hierarchy had no clue about what had transpired. Priorities were being set by the clerks and the programmers.

我们建议开发人员立即停止定制，让管理层参与进来，指派一名高级 IT 经理负责管理项目，如果项目无法在三个月内完成，则取消该项目。在我们的审计报告中，我们还提出了有关硬件的更大问题。如果几乎整个保险行业都使用 IBM 计算机，那么我们的客户需要认真考虑硬件交换，从霍尼韦尔到 IBM，而不是软件转换。未来购买的应用程序可能会使用 IBM 硬件。

We recommended the developers immediately stop the customization, involve management, task one of the senior IT managers with managing the project, and cancel the project if it could not be completed in three months. In our audit report we also raised the bigger question about hardware. If nearly the entire insurance industry employed IBM computers, our client needed to seriously consider a hardware swap, Honeywell to IBM, rather than a software conversion. Future purchased applications would probably utilize IBM hardware.

客户在 IT 部门进行了一些人事变动，并将一位经理提拔为首席信息官 (CIO) 后，决定停止软件转换工作，并启动硬件转换。我与客户合作了一年多，致力于这项工作。

After the client made some personnel changes in IT and elevated a manager to the chief information officer (CIO) position, it decided to pull the plug on the software conversion effort and initiate the hardware conversion. I worked with the client for more than a year on this effort.

这个故事说明了这个时代的四个 IT 趋势。首先，供应商提供的软件应用程序包的使用量正在增加。这些应用程序包通常会取代第一代内部开发的应用程序。对于会计、订单处理、库存管理等标准内部系统，供应商提供的解决方案通常价格更低、实施速度更快、风险更小。

This story illustrates four IT trends during this era. First, the use of software application packages supplied by vendors was increasing. These often replaced first-generation, internally developed applications. For standard internal systems for accounting, order processing, inventory management, and the like, vendors provided solutions at a lower price, with faster implementation, and less risk—usually.

在另一个客户那里，人力资源部门对 IT 部门非常失望，他们购买了一款没有 IT 部门参与的人力资源应用程序，然后又求助于 IT 部门来实施该应用程序。他们回复说：“抱歉。它看起来是一款不错的应用程序，但它运行在我们没有的计算机上。”这一事件表明 IT 部门和业务用户之间持续不断的斗争，而后者的反应是自己动手。

At another client, the human resources department became so frustrated with the IT department they purchased an HR application without IT involvement, then turned to IT for the application’s implementation. “Sorry” was the reply. “It looks like a fine application, but it runs on a type of computer we don’t have.” This incident was indicative of the ongoing struggles between IT and business users, and the latter’s response of doing it on their own.

其次，公司会转而“定制”软件包，或者让供应商来做，从而失去很多好处。每次供应商增强其软件时，都必须重新进行定制。即使不需要新功能，公司也需要保持软件包的更新，以便部署下一个更新。

Second, companies turned around and “customized” the package software, or had the vendors do it, losing much of the benefit. Every time the vendor enhanced their software, the customization had to be redone. Even if the new features weren’t needed, companies needed to keep the packages up-to-date so they could deploy the next updates.

这种定制热潮甚至延伸到了方法论上。我帮助中西部一家大型保险公司整合了 Warnier-Orr 的技术实践进入 Method/1。就在我们准备发布记录流程和表格的新笔记本时，你猜对了——安徒生推出了 Method/1 的新版本！当时还没有广泛使用的文字处理器，所以手册必须完全重新输入。

This customization craze even extended to methodology. I helped a large insurance company in the Midwest integrate Warnier-Orr technical practices into Method/1. Just as we were ready to publish the new notebooks full of processes and forms, you guessed it—Andersen came out with a newer version of Method/1! There were no word processors in wide use then, so the manuals had to be completely retyped.

第三，管理层除了抱怨成本之外，仍然不愿意深入研究 IT。高管们不了解这项技术及其影响。这种脱节部分是由于软件的无形性造成的。高管们了解如何建造新的制造厂 — — 这是有形的，他们可以亲眼监控进度。但软件就不那么了解了。

Third, management remained reluctant to delve into IT, other than grousing about the cost. Executives didn’t understand the technology or its impact. This disconnect was partially caused by the software’s intangibility. Executives understood building a new manufacturing plant—that was tangible, and they could monitor the progress with their own eyes. Software, not so much.

第四，随着套装软件公司开始涌现，IT 高管开始审视他们的应用程序资产组合，并认为“我们也可以成为一家令人兴奋的软件公司”。这种思维方式产生的大多数投资都以失败告终。仅仅因为某人可以运营内部 IT 部门，并不意味着他们能够在激烈的软件产品战争中生存下来。仅仅因为他们可以开发软件，并不意味着他们可以建立营销、销售、销售支持和客户服务组织。IT 商店相对而言不愿承担风险，而软件公司则不然。这种热潮很快就消失了。

Fourth, as package software companies began to sprout, IT executives began looking through their portfolio of application assets, thinking, “We could become an exciting software company, too.” Most of the investments that arose from this thought process resulted in abject failure. Just because someone could run an internal IT department, it didn’t mean they could survive the rough-and-tumble software product wars. Just because they could develop software, it didn’t mean they could build marketing, sales, sales support, and customer service organizations. IT shops were relatively risk averse; software companies weren’t. This fad fizzled out quickly.

技术

Technology

20 世纪 80 年代的代名词是索尼 Walkman，这是一款便携式磁带播放器，可让用户随时随地收听音乐。它是 iPod 和 iPhone 之后的首款便携式音乐设备。Walkman 重近一磅，是第一款 iPod 的三倍，每盒磁带包含 36 首歌曲，而 iPod 则包含 7,000 首歌曲。11便携式音乐^设备是接下来四十年的赢家。

The tech device synonymous with the 1980s was the Sony Walkman, a portable cassette player that enabled users to listen to music anywhere and anytime. It was the first of the portable music devices along the road to the iPod and then the iPhone. The Walkman weighed in at nearly a pound, three times as heavy as the first iPod, and each cassette contained 36 songs compared to the iPod’s 7,000 songs.¹¹ Devices used for portable music were winners for the next four decades.

11.比较容量可能比较棘手，因为它们会因年份、型号、歌曲长度等因素而变化，因此数字应该相互考虑，而不是绝对的。

11. Comparative capacities can be tricky because they vary by year, model, song length, and more, so numbers should be considered relative to each other rather than absolute.

虽然大型计算机仍然是商业计算的支柱，小型计算机的功能也越来越强大，但新设备开启了向个人提供计算机的趋势。1914 年至 1956 年担任 IBM 首席执行官的汤姆·沃森 (Tom Watson Sr.) 据说在 1943 年曾说过：“我认为全球市场可能需要五台计算机。”有些人认为沃森的话被误传了，但无论引用是否准确，在 20 世纪 40 年代到 70 年代，没有人梦想过计算设备的普及——除了 pos可能是漫画中的王牌侦探迪克·特雷西（1931-1977），他通过手表电话进行交流。每次我用 Apple 手表接听电话时，我都会想象特雷西的形象。

While mainframe computers remained the mainstay of business computing and minicomputers became more powerful, new devices initiated the trend to provide computers to individuals. Tom Watson Sr., CEO of IBM from 1914 to 1956, is reputed to have said in 1943, “I think there is a world market for maybe five computers.” Some think Watson was misquoted, but accurately quoted or not, no one in the 1940s through the 1970s even dreamed about the proliferation of computing devices to come—except possibly Dick Tracy, ace comic strip detective (1931–1977), who communicated via his watch-phone. Every time I answer a phone call on my Apple watch, I imagine Tracy.

IBM 发布了具有里程碑意义的个人计算机/2 (PS/2)；康柏推出了兼容 IBM 的便携式计算机 (28 磅)。我曾多次将我的计算机带上飞机。图形用户界面 (GUI) 出现在 Apple Macintosh 和 Lisa 计算机上，Mac 配备了第一款鼠标。面向对象编程 (OOP) 语言 C++ 引起了人们的关注，微软推出了 Windows，尽管它直到 20 世纪 90 年代仍然是一个真正的笨重产品。

IBM released its landmark Personal Computer/2 (PS/2); Compaq launched its IBM-compatible luggable (28 pounds). I lugged mine onto airplanes way too many times. Graphical user interfaces (GUI) appeared on the Apple Macintosh and Lisa computers, and the Mac sported the first mouse. The object-oriented programming (OOP) language C++ garnered attention, and Windows was launched by Microsoft, although it remained a real clunker until the 1990s.

如果这个故事反映了 20 世纪 80 年代计算机系统对待付费客户的方式，那么你可以想象内部用户面临的情况。缺乏客户友好型设计是由于过于注重内部用户、技术限制以及交互设计指南的新颖性造成的。

If this story indicates the way computer systems treated paying customers in the 1980s, you can imagine what internal users faced. This lack of a customer-friendly design was caused by a focus on internal users, technology limitations, and the newness of interactive design guidelines.

图 3.6显示了 20 世纪 80 年代流行的人机界面。12业务系统用户和软件开发人员^都能够从打孔卡和打印输出到非图形、基于字符的终端。这大大加快了周转速度。从计算机（大型机）到终端的连接是有线以太网¹³电缆，遍布整个计算机中心及其他地方的大量电缆箱。

Figure 3.6 shows the prevalent person–computer interface in the 1980s.¹² Both business systems users and software developers were able to advance from punch cards and printouts to nongraphical, character-based terminals. This sped up turnaround dramatically. Connectivity from the computers (mainframe) to the terminals was wire Ethernet¹³ cables spiderwebbed in massive cabling boxes throughout the computer center and beyond.

12.作为代沟的象征，当我的平面设计师第一次绘制这个图形时，他加入了一只老鼠。“这个时代没有老鼠”（针对使用基于字符的屏幕的业务系统）。

12. Symbolic of the generational divide, when my graphics designer first sketched this figure, he included a mouse. “No mice in this era” (for business systems that used character-based screens).

13.以太网是一种有线计算机网络技术，常用于局域网络连接计算机设备。它于 1980 年投入商业使用，并于 1983 年实现标准化。

13. Ethernet is a wired computer networking technology commonly used in local networks to connect computer devices. It was introduced commercially in 1980 and standardized in 1983.

里程碑方法论

Monumental Methodologies

结构化方法确实为软件开发带来了纪律和图形工具。这些都是思考和组织工具。在自动化业务流程以提高效率和降低成本很重要的时代，DFD 非常有用。实体关系图为图形分析和记录数据结构提供了一个很好的工具。

Structured methods did bring discipline and graphical tools to software development. These were thinking and organizing tools. DFD were useful during an era when automating business processes to increase efficiency and reduce costs was important. Entity-relationship diagrams provided a great tool for graphically analyzing and documenting data structures.

这些图表和方法被纳入了纪念碑式方法论 (MM)，并逐渐发展成为大量文档。MM 试图从无纪律的狂野西部转向更纪律、更正式的方法，但结果却事与愿违，把重点放在了错误的事情上——流程和文档。我们——包括我在内——误解了形式主义纪律。在尝试更好地组织和管理软件项目时，正式流程、阶段评审和文档增加了一定程度的官僚主义，掩盖了结构化技术的好处。正如一位朋友曾经打趣说的那样，“任何值得做的事情都值得做得过头。”我们的过度行为蓬勃发展。但那些将 MM 用作规则的人却陷入困境。那些将其用作适应自己情况的指导方针的人做得更好。这种规则与指导方针的方法将继续成为有效实施方法的关键。

These graphical diagrams and methods were incorporated into Monumental Methodologies (MM) that grew into tomes of documentation. Attempting to go from the undisciplined Wild West to a more disciplined, formal approach, MM overshot and focused on the wrong things—processes and documents. We—and that group includes me—mistook formality for discipline. In attempting to better organize and manage software projects, formal processes, phase reviews, and documentation added a level of bureaucracy that overshadowed the benefits of structured techniques. As a friend once quipped, “Anything worth doing is worth overdoing.” Our overdoing flourished. But those who used MM as rules floundered. Those who used them as guidelines to adapt to their situation did much better. This rules-versus-guidelines approach would continue to be critical to effective methodology implementation.

MM 的发展受到多种因素的推动。首先，软件工程¹⁴的出现部分基于将软件领域提升到合法、专业水平的愿望。土木工程等其他工程学科已通过严格的认证流程获得专业地位，成为“专业”工程师。软件工程支持者希望获得类似的合法性。

The evolution of MM was driven by several factors. First, the emergence of software engineering¹⁴ was in part based on the desire to elevate the software field to a legitimate, professional level. Other engineering disciplines such as civil engineering had gained professional status based on rigorous certification processes to become a “professional” engineer. Software engineering proponents wanted a similar level of legitimacy.

14. “软件工程”这个名称出现于1968年的北约会议上。

14. The name “software engineering” emerged at a 1968 NATO conference.

其次，总体管理仍陷于执行时代，命令控制风格盛行。确保“控制”是一项关键的管理绩效衡量标准。IT 项目通常被视为失控。业务经理通常对软件开发知之甚少，认为它一定类似于建造仓库；他们认为自己可以准确预测未来，从而控制结果。由于他们无法很好地掌握 IT 系统的价值，尽管业务生产力有所提高，但业务主管仍将注意力集中在“失控”的成本和进度超支上。

Second, general management was still mired in the execution era, in which the command-control style flourished. Assuring “control” was a key management performance measure. IT projects were generally viewed as out of control. Business managers often knew little about software development and assumed it must be akin to building a warehouse; they assumed they could accurately predict the future and, thereby, control outcomes. Because they lacked a good handle on the value of IT systems, even though business productivity increased, business executives focused on “out of control” cost and schedule overruns.

第三个因素是人们对项目管理的兴趣日益浓厚，部分原因是项目管理协会 (PMI) 的推动。由于许多项目管理实践是从建筑行业（例如船舶、制造厂）发展而来的，项目经理接受了连续、瀑布式流程的培训。

A third factor was the increasing interest in project management, in part driven by the Project Management Institute (PMI). Since many project management practices evolved from those in the construction industry (e.g., ships, manufacturing plants), project managers were schooled in serial, waterfall processes.

第四个因素是软件瀑布生命周期的出现，如本章后面的图 3.7所示。瀑布生命周期是软件开发的分水岭（双关语），我将在稍后详细介绍其概念和问题。

A fourth factor was the advent of waterfall life cycles for software, as shown in Figure 3.7 later in this chapter. Waterfall lifecycles were a watershed moment in software development (pun intended), with concepts and problems I will address in detail shortly.

这四个因素促进了瀑布式、控制导向、流程和文档密集型 MM 的形成和广泛使用。软件工程研究所的能力成熟度模型 (CMM) 获得了重大认证。这些方法的实施是通常是自上而下地从管理层到开发人员。除了采用结构化技术外，开发人员认为文档和流程是一种负担，而不是帮助。管理层要求使用 MM，而开发人员在寻找绕过流程的方法方面表现出色。

These four factors encouraged the formation and expanded use of waterfall, control-oriented, process- and documentation-heavy MM. Monumental certification came from the Software Engineering Institute’s Capability Maturity Model (CMM). Implementation of these methodologies was generally top down from management to development staff. Aside from employing structured techniques, developers considered the documentation and process a burden, not a help. Management dictated MM use and development staff excelled in finding ways around the processes.

20 世纪 90 年代，我曾在佛罗里达州的一家公司工作，该公司向美国和欧洲的中型公司销售财务软件。该公司的欧洲客户要求该公司保持国际标准化组织 (ISO) ¹⁵认证。遵循所需的文档、流程和签收做法并不能确保取得多大进展，因此员工想方设法绕过它们。定期的 ISO 审计会发现问题，需要花费数小时来应对审计——这是一个循环往复的噩梦。尽管 ISO 指南允许修改已批准的做法，但该公司不愿意修改它们，因为这需要额外的 ISO 审查。

During the 1990s, I worked with a company in Florida that sold financial software to medium-size companies in the United States and Europe. Its European customers required the company to maintain International Organization for Standardization (ISO)¹⁵ certification. Following the required documentation, process, and sign-off practices ensured little progress, so staff found ways around them. The periodic ISO audits would find issues, requiring hours of work responding to the audit—a nightmare of going around in circles. Although ISO guidelines allowed modifications to the approved practices, the company was reluctant to modify them since it would require additional ISO review.

15、对质量控制的反思。

15. Reflected thinking about quality control.

MM 中最具里程碑意义的是信息工程 (IE)，这是 James Martin 和 Clive Finkelstein 创立的一种方法。IE 是 IT 的终极自上而下、长期规划方法。它提倡一个漫长的战略规划过程，然后是支持所有已确定系统的企业数据模型，将这些系统打包成项目，最后，在 2 到 3 年后，您将开始实施。IE 对大多数结构化方法论者来说是一种诅咒。尽管如此，渴望控制和了解快速增长的 IT 预算的 IT 和高级业务主管还是成群结队地参加了 IE 研讨会。

The most monumental of the MM was information engineering (IE), an approach founded by James Martin and Clive Finkelstein. IE was the ultimate top-down, long-range planning approach to IT. It advocated a lengthy strategic planning process, followed by enterprise data models that supported all the identified systems, packaging those systems into projects, and finally, after 2 to 3 years, you would begin implementation. IE was an anathema to most structured methodologists. Nonetheless, IT and senior business executives, yearning for control and understanding of their rapidly growing IT budgets, attended IE workshops in droves.

瀑布

Waterfall

温斯顿·罗伊斯 (Winston Royce) 于 1970 年发表的一篇论文被普遍认为是“瀑布”趋势的开端。事实上，罗伊斯提倡对任何比简单项目更复杂的项目都采用迭代开发。考虑到当时的串行“硬件”思维模式，很容易看出他的串行瀑布图是如何流行起来的，尽管他在论文中解释了它的危险性。

A 1970 paper by Winston Royce is generally credited with starting the “waterfall” trend. In reality, Royce was an advocate of iterative development for anything more than simple projects. Given the serial “hardware” mindset of the time, it’s easy to see how his serial waterfall diagram took hold, even though he explained its dangers in his paper.

Larry Constantine 评论道：“Ed [Yourdon] 和我将这个模型设想为一种‘训练轮’，但它在管理方面却大获成功。”当我向 Larry 询问瀑布生命周期的并发思维时，他并不知道 Royce 的论文。由于当时瀑布式阶段在管理实践中得到广泛应用，因此它们在软件开发中的使用日益广泛也就不足为奇了。同样有趣的是，Larry 和Ed 认为瀑布方法只是新兴软件开发人员的“训练轮”，并不适合用于严肃的项目。

Larry Constantine commented, “Ed [Yourdon] and I conceived that model as a form of ‘training wheels’ but it took off with management.” When I queried Larry about the concurrent thinking about waterfall life cycles, he was not aware of Royce’s paper. Since waterfall-like stages were becoming widely used in management practices at the time, their growing use in software development wasn’t surprising. It’s also interesting that Larry and Ed considered waterfall approaches to be “training wheels” for budding software developers and not for use in serious projects.

瀑布思维远远超出了软件的范围，使得向迭代方法的过渡变得困难。图 3.7显示了与此技术相关的软件瀑布生命周期和组织结构图。瀑布生命周期受到当时周围环境的影响——功能组织层次结构和项目管理的串行方法。瀑布非常适合。IT 被组织成与瀑布结构一致的功能组——需求组、设计组、编程组等。随着时间的推移，这些组与其他组变得孤立，每个组都在其指定组中很好地工作，但它们之间却竖起了障碍。分析师与设计师争执不休，程序员与测试人员争执不休，IT 以外的每个人都与 IT 争执不休。

Waterfall thinking extended far beyond software, making the transition to iterative methods difficult. Figure 3.7 shows the software waterfall life cycle and organizational structure diagrams associated with this technique. The waterfall life cycle was greatly influenced by the surrounding ethos of the times—functional organization hierarchies and serial approaches to project management. Waterfall fit right in. IT was organized into functional groups aligned to the waterfall structure—requirements groups, design groups, programming groups, and more. Over time, these groups became isolated from the other groups, with each working well within its designated group, but erecting barriers between them. Analysts feuded with designers, programmers feuded with testers, and everyone outside IT feuded with IT.

瀑布假设认为，文档足以在团队之间进行沟通。人们认为文档或图纸可以完整准确，无需进一步解释^。16

A waterfall assumption was that documentation was sufficient to communicate between groups. The belief was that documentation, or drawings, could be complete and accurate with no need for further explanation.¹⁶

16.我在 20 世纪 90 年代看过一次会议报告，其中讨论了需求的准确性和完整性问题。我始终找不到这项研究，也找不到做这项研究的人，因此以下记忆中有一个很大的警告：平均需求文档的完整性不到 20%，正确性不到 10%。我认为这些数字太低了，但它们仍然令人吃惊。

16. I saw a conference presentation in the 1990s that addressed requirements accuracy and completeness issues. I could never find the study or who did it, so a big caveat accompanies the following memory: The average requirements document was less than 20% complete and less than 10% correct. I think these numbers are too low, but they are nevertheless startling.

20 世纪 90 年代初，我接到一个电话咨询。开发经理说：“我们需要一个需求定义类。”

I received a phone inquiry in the early 1990s. “We need a requirements definition class,” said the development manager.

我没有仅仅背诵课堂上的内容，而是问：“你为什么需要这门课？”

Rather than just recite what was included in my class, I asked, “Why do you need the class?”

“嗯，”经理说。“我们想把开发工作外包给印度，需要确保规格齐全。”

“Well,” said the manager. “We want to outsource development to India and need to make sure the specs are complete.”

“你今天的规格有多完整？”我问道。“你认为他们应该有多完整才能将编程外包出去？”

“How complete are your specs today?” I asked. “And, how complete do you think they should be to outsource programming?”

“我估计我们今天已经完成了约 50%，我希望能完成 80% 以上。”

“I would estimate we are about 50% complete today and I would like to get over 80%.”

“嗯，几项行业研究和我的观察表明，你们的百分比被严重高估了。最后一个问题：贵公司的新员工需要多长时间才能充分了解环境，从而提高工作效率？”

“Well, a couple of industry studies and my observations would indicate your percentages are significantly overestimated. One final question: How long does it take for new hires in your firm to learn enough about your environment to be productive?”

“我们的环境相当复杂，所以大约六个月。”答复说。

“Our environment is pretty complex, so about six months,” was the reply.

“如果规范的准确度和完整性最多只能达到 20% 到 25% 的水平，而当人们坐在你的办公室里时需要六个月的时间才能了解一组规范的背景，那么你将如何将这些背景信息传达给印度的员工并回答不可避免的一系列问题？”

“If the accuracy and completeness of specifications are in the 20% to 25% range, at best, and it takes six months when the people are sitting in your office to learn the context for a set of specifications, then how will you convey this context information to the staff in India and answer the inevitable list of questions?”

他若有所思地说：“我没有考虑过这些问题。”我们挂了电话，我再也没有收到回复。我知道制作更好的需求文档并不能解决他的问题。

He mused, “I hadn’t considered those issues.” We hung up and I never heard back. I knew producing a better requirements document wasn’t going to solve his problem.

这些事件影响了我对职能孤岛、文档有效性和协作必要性的思考。我将这些日益增长的担忧带入了下一个 Roots 时代。

These kinds of incidents influenced my thinking about functional silos, the effectiveness of documentation, and the need for collaboration. I carried these growing concerns into the next Roots era.

瀑布生命周期固有的沟通问题催生了解决方案——矩阵管理和跨职能团队。项目经理向项目管理办公室汇报，但也管理一个项目团队（在 IT 组织中通常有多个项目团队）。20 世纪 70 年代，矩阵管理开始流行，并在 20 世纪 80 年代得到扩展，尤其是在项目管理领域。在矩阵组织中，一名员工可以有两名（或更多）经理。在软件项目中，项目团队成员可能来自职能组织，例如分析、数据库设计、编程、测试和项目管理。团队成员向项目经理汇报工作任务和结果，向其职能经理汇报人力资源事项，例如绩效评估、加薪和培训。

The communications issues inherent in the waterfall life cycle gave rise to solutions—matrix management and cross-functional teams. Project managers reported to the project management office, but also managed a project team (and usually several in IT organizations). In the 1970s, matrix management became popular, and it expanded in the 1980s, particularly in project management. In a matrix organization, an individual employee could have two (or more) managers. On a software project, project team members might come from functional organizations, such as analysis, database design, programming, testing, and project management. Team members reported to the project manager for work tasks and results, and to their functional manager for human resources items such as performance reviews, pay increases, and training.

不难看出这种组织方法是如何遇到麻烦的，尤其是在敏捷时代开始时。IT 部门长期缺少项目经理和数据库管理员 (DBA)，因此项目经理负责监督多个项目，而 DBA 则担任多个团队的主题专家 (SME)。开发人员可能被分配到多个团队，并负责持续的维护。这些组织解决方案导致了问责噩梦：“我无法完成任务 Y，因为 DBA 正忙于另一个项目。”忠诚的对象是职能组，而不是项目范围、进度和成本，更不用说客户价值了。

It’s not difficult to see how this organizational approach ran into trouble, especially as the Agile era began. IT departments were chronically short of project managers and database administrators (DBA), so project managers supervised several projects and DBAs acted as subject-matter experts (SME) for multiple teams. Developers might be assigned to several teams, plus ongoing maintenance. These organizational solutions caused accountability nightmares: “I couldn’t complete task Y because the DBA was busy on another project.” Allegiance was to functional groups, not to project scope, schedule, and cost, much less to customer values.

IT 部门以外的部门调整了工作，以符合序列化、瀑布式的思维模式。法律部门根据特定文件的序列交付来制定合同。会计部门根据序列模型制定了对运营成本和资本成本进行分类的标准。采购和人力资源部门也纷纷效仿。

Departments outside of IT adapted their work to conform to the serial, waterfall mindset. Legal departments created contracts based on the serial delivery of specific documents. Accounting departments established standards for classifying operating versus capital costs based on the serial model. Purchasing and human resources departments followed suit.

20 世纪 80 年代末，随着 Barry Boehm 的螺旋模型和 Tom Gilb 的进化模型的引入，软件对瀑布式开发的依赖开始发生变化。Gilb 使用“进化”一词来描述一种迭代方法，该方法采用小型、精心规划的开发周期。Boehm 的螺旋模型明确纳入了基于风险推动开发的概念。这两个生命周期都是迭代的，它们通过采取较小的步骤并测试结果来解决不确定性。每个步骤的可交付成果都包含在总体项目计划中，该计划通常会在每次后续迭代中修订。

The reliance on waterfall development in software began to change in the late 1980s with the introduction of Barry Boehm’s spiral model and Tom Gilb’s evolutionary model. Gilb used the term “evolutionary” to describe an iterative approach with small, well-planned development cycles. Boehm’s spiral model explicitly incorporated the concept of driving development based on risk. Both life cycles are iterative, and they address uncertainty by taking smaller steps and testing the results. Each step’s deliverables are included in an overall project plan, which is then usually revised at each subsequent iteration.

瀑布生命周期有一个隐藏的缺陷，少数人已经揭露了这一点。瀑布生命周期中的每个阶段都有一个框（过程）和一个指向下一个过程的箭头。然而，在每个箭头的中间，需要有一个三角形框，上面写着“魔法就在这里”，如图 3.8所示。从需求到设计再到编程的转换不是算法性的，MM 和 CASE 工具在这个很少被讨论的缺陷上挣扎。也许它们应该被称为不朽的神话。

The waterfall life cycle had a hidden flaw that a few individuals had exposed. Each stage in a waterfall life cycle has a box (process) and an arrow to the next process. However, in the middle of each arrow there needs to be a triangular box with the words, “Here lies magic,” as shown in Figure 3.8. The transitions between requirements to design to programming are not algorithmic, and MM and CASE tools floundered on this rarely discussed flaw. Maybe they should have been called Monumental Mythologies.

将设计转化为代码不是一个定义好的、可自动化的过程；而是一个需要“思考”的经验过程。克服这一缺陷需要魔法。敏捷专家 Ken Schwaber 后来在对经验过程和定义过程的研究中指出了这一差异。定义过程是算法的；经验过程不是。Tom DeMarco 在我们的讨论中谈到了这个问题：“使用左脑方法解决本质上多维的问题是我们当时软件开发方法的悲剧性缺陷。”

Transforming design into code is not a defined, automatable process; it is an empirical one requiring “thought.” Overcoming this flaw requires magic. Agilist Ken Schwaber later noted this difference in his investigation of empirical versus defined processes. Defined processes are algorithmic; empirical processes are not. Tom DeMarco touched on this issue in our discussion: “Using left-brain methods for an inherently multidimensional problem was the tragic flaw of our then approach to software development.”

试图将算法转换为经验过程会导致灾难。出于这个原因，我主张对敏捷方法使用“可靠”一词，而不是在定义的过程中使用“可重复”一词。魔法会有很大帮助，但只适用于哈利波特。

Trying to impose an algorithmic conversion to an empirical process leads to disaster. For this reason, I’ve advocated using the term reliable for agile methods rather than the term repeatable used in defined processes. Magic would be a great help, but only for Harry Potter.

我可能在这里对定义有点偏颇，但这个“魔法”三角可能定义了软件工程师和软件开发人员之间的核心区别。在将客户需求转化为软件应用程序的过程中，技术已经提供了大幅缩小“魔法差距”的手段——从 20 世纪 70 年代的主要工具编译器到如今 Azure（来自微软）等完整平台。我认为软件工程师相信，在某个时间点，魔法差距是可以消除的；软件开发人员却不这么认为。我站在开发人员一边，这也是我更喜欢在本书中使用这个术语的原因之一。

I may be going out on a definitional limb here, but this “magic” triangle may define the core difference between software engineers and software developers. In the translation of customer needs to a software application, technology has provided the means to shrink the “magic gap” dramatically—from compilers as the main 1970s tool to complete platforms like Azure (from Microsoft) today. I think software engineers believe that at some point in time, the magic gap can be eliminated; software developers don’t think it can. I’m with the developers, which is one of my reasons for preferring that term in this book.

因此，序列思维并非软件管理的发明，但它渗透到了当时管理者的思维中。不幸的是，它也是组织必须解决的敏捷实施的一个障碍。

So, serial thinking was not an invention of software management, but it permeated managers’ thinking at the time. Unfortunately, it was also an impediment to agile implementations that organizations had to address.

管理

Management

20 世纪 80 年代，管理风格开始从执行型向专业型转变。随着生物技术、计算机、材料科学、医疗技术以及其他领域的知识工作增加，对知识工作者的需求也随之增加。数字革命来临，随之而来的是随着工人阶级的不断壮大，管理工人的模式也发生了变化。“找到工作并坚持下去”的职业模式正在瓦解。知识型员工开始对自己的职业比对雇主更忠诚，而且由于拥有多种就业机会，他们开始远离传统职业。新技术公司的迅速崛起以及股票期权带来的高薪前景推动了这些变化。随着从在同一家公司终身工作的期望转变为 21 世纪的零工经济，即“工作”与项目挂钩，雇主与雇员的关系正在发生变化。

During the 1980s, management style began the transition from execution to expertise. As knowledge work increased in biotechnology, computers, materials science, medical technology, and in every other field, the need for knowledge workers increased. The Digital Revolution was upon us, and with this burgeoning class of workers came the need to modify how to manage them. The “get a job and stay there” career model was breaking down. Knowledge workers began to have more loyalty to their profession than to their employers and with multiple employment opportunities, they began to move away from traditional careers. The rapid rise of new technology companies and the prospect of big paydays from stock options helped fuel the changes. With the shift from the expectation of a lifelong career with the same company to the 21st-century gig economy where “jobs” were tied to a project, changes in employer–employee relationships were occurring.

在结构化时代，项目管理 (PM) 在软件开发中的应用越来越广泛。我开始阅读和研究 PM，并将我所学的知识与我所经历的知识相结合。随着越来越多的 PM 实践融入到 Monumental 方法论中，我开始教授与 DSSD 相关的初级 PM 研讨会。

DURING THE STRUCTURED ERA, project management (PM) was increasingly used in software development. I began to read about and study PM and to integrate what I had learned with what I had experienced. I started teaching a rudimentary PM workshop associated with DSSD as increasingly PM practices were baked into Monumental Methodologies.

当时，与软件开发相关的最著名的书是弗雷德·布鲁克斯 (Fred Brooks) 的《人月神话》 (1975)。布鲁克斯是 IBM/360 系列计算机的 IBM 操作系统 (OS) 开发经理，这可能是迄今为止最大的软件项目。在分析了几个 OS 项目的表现后，他得出了最著名的结论：“在延期的项目中增加人员只会让项目更晚。”他注意到管理人员往往会重复这样的错误，他打趣说他的书被称为软件工程圣经，“因为每个人都引用它，有些人读它，有些人去买它。”这种观点同样适用于当今的敏捷方法实施。

At the time, the most famous book related to software development was The Mythical Man-Month by Fred Brooks (1975). Brooks was the manager of the IBM operating system (OS) development for the IBM/360 line of computers, probably the largest software project to date. After analyzing performance on several OS projects, he reached his most famous conclusion: “Adding people to a late project just makes it later.” Noting managers tended to repeat such errors, he quipped his book was called the Bible of Software Engineering “because everybody quotes it, some people read it, and a few people go buy it.” That sentiment could be applied equally to today’s agile methodology implementations.

在狂野西部和结构化时代使用的项目管理实践最适合有形产品，最初是建筑类型的项目，对于这种项目来说，串行方法很有效。软件更具可塑性这一事实并没有影响项目的管理方式，坦率地说，软件开发在起步阶段本身并没有太大的可塑性。项目经理专注于任务，而不是人员和团队动态。

The PM practices used during the Wild West and Structured eras were best suited for tangible products, initially construction-type projects, for which a serial approach worked. The fact that software was more malleable didn’t impact how projects were managed, and frankly software development in its infancy wasn’t overly malleable itself. Project managers focused on tasks, rather than on people and team dynamics.

20 世纪 80 年代，项目经理开始采用风险和问题管理等实践。1987 年，PMI 发布了第一部项目管理知识体系，由此产生了与软件开发方法论配套的 PM 里程碑方法论。此后不久，在 1989 年，PRINCE方法论发布并成为欧洲大部分地区的标准项目管理方法论。

In the 1980s, project managers incorporated practices such as risk and issue management. The first Project Management Body of Knowledge was published in 1987 by the PMI, which led to a PM Monumental Methodology to accompany those for software development. Shortly thereafter, in 1989, the PRINCE methodology was published and became the standard PM methodology in much of Europe.

一个重要的新项目管理理论源自 Eliyahu Goldratt (1984) 的小说《目标：持续改进的过程》。他的约束理论表明，价值创造始终存在一个主要的“瓶颈”，减少或消除这个瓶颈可以提高产量。当然，消除第一个瓶颈会带来下一个瓶颈。这个原则意味着执行非瓶颈活动的人员必须尽一切可能减少从事瓶颈活动人员的工作量，即使这意味着他们自己效率低下。Goldratt 称这种方法为“关键链”；与传统关键路径法不同，它侧重于识别和消除限制产量的约束。Goldratt 继续撰写《关键链》（1997），将这些实践应用于项目管理。

One important new project management theory emerged from a novel, The Goal: A Process of Ongoing Improvement, by Eliyahu Goldratt (1984). His theory of constraints showed that there was always one primary “bottleneck” to value generation, and reducing or eliminating it would increase throughput. Of course, eliminating the first bottleneck would uncover the next one. This principle meant people performing non-bottleneck activities must do everything possible to minimize the amount of work for those engaged in bottleneck activities, even if it meant being somewhat inefficient themselves. Goldratt called this approach “critical chain”; in contrast to the traditional critical path method, it focused on identifying and removing constraints that limited throughput. Goldratt went on to author Critical Chain (1997), applying these practices to PM.

高德拉特的理论后来被敏捷社区所接受，并影响了敏捷宣言的简单原则：“最大限度地减少未完成工作量的艺术至关重要。”敏捷实践包括创建功能积压，其中几个功能在每次迭代中发布给开发团队。优先发布功能不应使团队负担过重，尤其是那些关键链上的团队。20 世纪 90 年代，我与一位开发经理交谈，他抱怨他的部门项目停滞不前。我问他有多少个项目和多少人。答案是：43 个项目和 42 个人。很容易推断，他有大量的在制品“库存”，但产出很少。每个人都忙于（高效地）建立在制品库存，但没有有价值的产出。

Goldratt’s theories were embraced later by the agile community and influenced the Agile Manifesto principle of simplicity: “The art of maximizing the amount of work not done is essential.” Agile practices include creating a backlog of features, a few of which are released to development for each iteration. Prioritizing feature release should not overload the team, especially those on the critical chain. In the 1990s, I spoke to a development manager who lamented his department projects were stalled. I asked him how many projects and people he had. The answer: 43 projects and 42 people. It was easy to surmise that he had high in-process “inventory” but little output. Everyone was busy (productive) building up the inventory of work in process, but there was no throughput of value.

这个十年也开始了 PM 软件向个人计算机的过渡，包括1984 年第一个商业版本的 Microsoft Project (DOS) ^{17 。}

This decade also began the transition of PM software to personal computers, including the first commercial version of Microsoft Project (DOS)¹⁷ in 1984.

17.微软磁盘操作系统，在 Windows 出现之前，该系统在个人电脑上占据主导地位。

17. Microsoft Disk Operating System, which dominated PCs prior to Windows.

在过去的六十年里，衡量软件开发成功的标准已经从完成度演变为客户价值。没有什么比组织衡量成功的方式更能推动变革，但没有什么比这些衡量标准更难改变。投资回报率 (ROI) 对组织有影响，客户价值则有影响。在 IT 组织中，进度会驱动某些行为。在早期，只要完成一个项目就足够成功了；到了世纪之交，其他衡量标准占据了主导地位。我曾与一家公司合作，该公司通过交付的代码行数来衡量程序员，测试人员按发现的 bug 数量¹⁸进行奖励。这奖励程序员提高编码效率，而只在口头上强调质量。测试人员因发现 bug 而获得奖励，因此他们没有任何动力去要求更高质量的代码。这些措施也不利于两组之间的协作，因此反馈循环被最小化。幸运的是，大多数测试人员和程序员都具有提供高质量产品的内在动力，并且经常因这些糟糕的基于活动的激励结构而感到受阻。

OVER THE LAST SIX decades, measures of software development success have evolved from completion to customer value. Nothing drives change like the way organizations measure success, but few things are harder to change than those measures. Return on investment (ROI) impacts organizations one way, customer value another. In IT organizations, schedule drives certain behaviors. In the early days, just completing a project was success enough; by the turn of the century, other measures ruled. I worked with one company that measured programmers by lines of code delivered and testers by number of bugs¹⁸ found. This rewarded programmers for coding productivity with only lip service given to quality. Testers were rewarded for finding bugs, so they didn’t have any incentive to ask for better-quality code. These measures also worked against collaboration between the two groups, so the feedback loops were minimized. Luckily, most testers and programmers possessed an internal motivation to deliver quality products and often felt stymied by these poor activity-based incentive structures.

18. Bug是一个用来描述代码缺陷的术语。该术语由海军上将 Grace Hopper 于 1946 年创造，用于解释硬件问题。在软件开发中，它可能因推卸责任而变得突出。开发人员应对缺陷负责。相反，Bug会自行爬入您的代码中。

18. Bug is a term that has been used to describe a defect in code. The term was coined by Admiral Grace Hopper in 1946 to explain a hardware problem. In software development, it may have risen to prominence to deflect responsibility. A developer is responsible for a defect. Bugs, in contrast, crawl into your code all by themselves.

在可预测的旧世界中，软件开发的成功衡量标准借鉴了制造业的统计质量控制理论。在制造工厂中，将金属和塑料制成小部件，该过程需要可重复，一次又一次地符合严格的公差。正如我们将看到的，软件与小部件不同。

In the predictable world of old, software development measures of success borrowed from manufacturing’s statistical quality control theories. In a manufacturing plant, turning metal and plastic into widgets, the process needed to be repeatable, conforming to tight tolerances time after time. Software differs from widgets, as we will see.

随着绩效趋势的演变，为工业时代发展起来的基于活动的衡量标准（如生产力）几乎从未在知识时代发挥作用，并且在创新时代被视为一种诅咒。

As performance trends evolved, activity-based measures, like productivity, that had evolved for the Industrial Age almost never worked for the Knowledge Age and were an anathema in the Innovation Age.

CASE 工具

CASE tools

失控图表和文档的解决方案是什么？当然是自动化。IT 的任务是实现业务流程自动化，那么为什么不实现业务流程自动化呢？虽然早期有 CASE 工具供应商，但当马萨诸塞州剑桥的 Index Technologies 开始为 IBM PC 营销其 Excelerator 产品时，市场迅速扩大，因为个人电脑在企业中变得无处不在。Excelerator 成为 CASE 工具市场的领导者。它支持结构化图形（例如 DFD 和实体关系图），拥有一个用于存储数据存储详细信息的数据存储库，并提供逻辑详细信息。

What is the solution to runaway diagrams and documentation? Automation, of course. IT was tasked with automating business processes, so why not automate their own? While there were earlier vendors of CASE tools, the market expanded rapidly when Index Technologies in Cambridge, Massachusetts, began marketing its Excelerator product for the IBM PC, as personal computers were becoming ubiquitous in businesses. Excelerator became the CASE tool market leader. It provided support for structured graphics such as DFD and entity-relationship diagrams, had a data repository for details about data stores, and provided logic details.

其他著名的 CASE 工具（到 20 世纪 90 年代初已有近 100 家供应商）包括 Andersen Consulting 的 Foundation、Yourdon 的 Analysis/Designer 工具包、Learmonth & Burchett Management Systems 的 Automate Plus 和 Nastec Corp 的 DesignAid。这些 CASE 工具具有类似的功能，但有些更倾向于结构化图形（例如 Excelerator 和 Analysis/Designer），而其他一些则更倾向于捕获文档（例如 Foundation 和 Automate Plus）。每个人都跃跃欲试有机会成为爆炸式增长市场的领导者——而且它确实爆发了。方法论行业中的每个人都急于开发自己的 CASE 工具，而我们 KOA 则创建了我们的版本——设计机器（稍后会详细介绍）。

Other prominent CASE tools—there were nearly 100 vendors by the early 1990s—were Foundation from Andersen Consulting, Analysis/Designer toolkit from Yourdon, Automate Plus from Learmonth & Burchett Management Systems, and DesignAid from Nastec Corp. These CASE tools had similar functionality, but some leaned toward structured graphics (e.g., Excelerator and Analysis/Designer), while others leaned toward capturing documents (e.g., Foundation and Automate Plus). Everyone was jumping at the chance to become a leader in an exploding market—and explode it did. Everyone in the methodology business rushed to develop their own CASE tool, and we at KOA created our version—the Design Machine (more on this later).

CASE 工具的吸引力显而易见，但现实却并非如此。它们遭遇了众多问题。首先，在当时和未来，高管和经理们都在寻找所谓的“灵丹妙药”，即能够解决所有 IT 问题的东西。对 CASE 工具的期望不切实际，成本也不高。购买和培训员工使用它们都很昂贵。实现可接受的投资回报率很成问题。

The allure of CASE tools was obvious, but the reality was different. They suffered from a plethora of problems. First, during this era and the next, executives and managers were looking for the proverbial “silver bullet,” the one thing that would solve all their IT problems. Expectations for CASE tools were unrealistic, and so were the costs. They were expensive both to purchase and to train staff to use. Achieving an acceptable ROI was problematic.

其次，缺乏标准带来了挑战。每个人似乎都有自己的想法，关于使用哪些图表，甚至要采用哪种图表风格。使问题更加复杂的是，人们对面向对象方法的兴趣日益浓厚，这引入了一组新的图表。后来，统一建模语言 (UML) 的开发为下一代工具解决了这个问题。

Second, the lack of standards created challenges. Everyone seemed to have their own ideas about which diagrams to use and even which flavor of those diagrams to embrace. Compounding the problem was the rising interest in object-oriented approaches, which introduced a new set of diagrams into the mix. Later, the development of Unified Modeling Language (UML) solved this problem for the next generation of tools.

第三，最流行的工具 Excelerator 运行在 IBM PC 上，而 IBM PC 在大部分时期都没有联网，因此每个人都有自己的数据和图形版本。方法、工具、供应商和图表方面的差异导致结果不完整且令人困惑。IBM 提出了一种集成解决方案，即使用其 AD/Cycle 系统来解决这些问题，但其开发范围和糟糕的时机（耗时太长）使这一努力泡汤。

Third, the most popular tool, Excelerator, ran on IBM PCs, which for much of the period were not networked, so everyone had their own versions of data and graphics. Differences in methodologies, tools, vendors, and diagramming led to unintegrated and confusing results. IBM proposed an integrated solution to these issues with its AD/Cycle system, but the scope of its development and poor timing (took too long) scuttled the effort.

第四，20 世纪 90 年代，部署技术转变如此之快，CASE 工具公司受到了巨大冲击，从基本连接到客户端-服务器架构（一种试图将个人电脑等单个设备联网的架构），然后又快速过渡到互联网。

Fourth, the deployment technology transitioned so rapidly during the 1990s that CASE tool companies got whipsawed, from basic connectivity to client-server architectures (an architecture that sought to network individual devices such as PCs) and then a rapid transition to the Internet.

第五，继续使用瀑布生命周期，并认为可以详细指定整个开发过程，这导致了错误的假设，即在指定需求之后，只需按一下按钮即可自动化其余部分。

Fifth, the continued use of the waterfall life cycle and the belief the overall development process could be specified in detail led to the erroneous assumption that after the requirements were specified, the rest could be automated at the push of a button.

最后，当我们讨论 CASE 工具时代的快速崛起和随后的衰落时，Dave Higgins 提出了一个问题。Dave 说：“我认为 CASE 工具时代的失败是微妙的潜在假设，即程序员的工作可以自动化。我们要求程序员构建和实施系统来取代自己！即使在今天，低代码技术也威胁着同样的结果。但我认为这过去是、现在是、将来也将是一个白日梦。我们永远需要开发人员。”

Lastly, there was the issue Dave Higgins brought up in our conversation when we discussed the rapid rise and subsequent fall of the CASE tool era. Dave said, “What I think doomed the CASE tool era was the subtle underlying assumption that programmers’ jobs could be automated. We were asking programmers to build and implement systems to replace themselves! Even today low-code technology threatens the same outcome. But I think it was, is, and will be a pipe dream. We will always need developers.”

这个灵丹妙药问题让我想起了一位教育工作者分享的一次飞机旅行对话。她的邻座问她：“你认为什么能解决我们的公共教育问题？”

The silver bullet issue reminded me of a story an educator shared about a plane trip conversation. Her seatmate asked her, “What do you think is the one thing that would solve our public education problems?”

她立即​​回答说：“人们认为有一种方法可以解决我们的公共教育问题。”

To which she instantly replied, “People who think there is one thing that will solve our public education problems.”

当我们尝试使用灵丹妙药来解决复杂问题时，我们失败了。

We fail when we attempt to use silver-bullet solutions to complex problems.

我喜欢温伯格的名言，因为它突出了强调事物（子弹）和强调人（甚至是像独行侠这样的虚构人物）之间的二分法。我对温伯格的名言进行了更进一步的阐释。

I like Weinberg’s quote because it highlights the dichotomy between an emphasis on things (bullets) and an emphasis on people (even a fictional character like the Lone Ranger). I took Weinberg’s quote another step further.

对于大多数人来说，困难的部分是了解不同类型的子弹以及每种子弹最有可能成功的情况。

For most, the hard part is understanding the different types of bullets and the situations in which each is most likely to succeed.

KEN ORR 设想了我们自己的 CASE 工具，称为 Design Machine，部分资金来自一家大型咨询客户。产品的名称本身就表明了软件开发的假定规范性。这和其他问题导致了公司的倒闭——并不是每一次冒险都能成功。本着记录失败和成功的精神，我将详细介绍这一历程。

KEN ORR ENVISIONED our own CASE tool, called the Design Machine was partially funded by a large consulting client. The product’s very name indicated the assumed prescriptive nature of software development. That and other issues led to the demise of the company—not every adventure works out. In the spirit of documenting failures as well as success, I will go into a bit of detail on this journey.

随着 KOA 将 Design Machine 产品添加到我们的培训和咨询产品组合中，需要额外的投资资金来资助产品开发、销售和营销。风险资本的注入伴随着重组的条件。引入了新的执行人员；肯成为负责产品开发的首席技术官；新公司名称“Optima”成立；总办事处迁至芝加哥，肯和 Design Machine 开发人员留在托皮卡。

As KOA added the Design Machine product to our portfolio of training and consulting, additional investment funds were needed to fund product development, sales, and marketing. An infusion of venture capital came with conditions for reorganization. A new executive staff was brought in; Ken became the chief technology officer responsible for product development; a new company name, “Optima,” established; and the general offices were moved to Chicago, leaving Ken and the Design Machine development staff in Topeka.

麻烦随即开始。新的管理人员与开发人员或现场顾问（大部分收入来自他们）相处不融洽。公司扩大了销售和营销人员，开设了几个新的销售办事处。不幸的是，当时的产品还不足以保证如此庞大的销售人员。1986 年，肯找到我，让我全职回到公司工作。我的正式职位是产品经理；我的非官方角色是派系之间的调解人。我赢得了顾问们的尊重和友谊，并与新任高管建立了良好的工作关系。我开始每周从亚特兰大通勤到芝加哥。但这是一场与时间的赛跑。

Trouble started immediately. The new management staff didn’t get along with the development staff or the consultants in the field (who generated most of the income). The company expanded its sales and marketing staff, opening several new sales offices. Unfortunately, there weren’t yet enough products to warrant such a large sales staff. In 1986, Ken approached me to come back to work at the company full-time. My official job title would be product manager; my unofficial role would be mediator between the factions. I had the respect and friendship of the consultants and developed a good working relationship with the new executives. I began commuting from Atlanta to Chicago each week. But it was a race against time.

新任主管、新销售人员和新办公室迅速耗尽了资金。与所有创新软件产品开发一样，Design Machine 的进度也落后了。有一次，我在托皮卡教授一个为期四天的公开系统设计研讨会。Design Machine 团队的几位开发人员参加了研讨会。当我从他们的问题中意识到他们并不真正理解我们方法的基本概念时，我心中响起了警钟。Design Machine 几乎没有任何将变化反馈给前几个阶段的措施！它是自动化规范的串行瀑布过程的终极手段。

New executives, new sales staff, and fancy new offices drained cash quickly. As with all innovative software product developments, the Design Machine schedule slipped. At some point I was in Topeka to teach a public four-day systems design workshop. Several of the developers from the Design Machine team attended the workshop. A red flag went off in my head when I realized from their questions that they didn’t really understand fundamental concepts of our methodology. The Design Machine had almost no provision for feeding back changes to previous stages! It was the ultimate in automating a prescriptive serial waterfall process.

为了挽回颓势，风险投资家解雇了新任管理人员。肯回来担任总裁，我接任咨询副总裁。但资金流失太严重，Optima 在六个月内倒闭了。除了几笔“内部”销售外，我们从未将 Design Machine 推向 CASE 工具市场。肯辞职了，为了从这场灾难中挽回一点，风险投资家给了我总裁/首席执行官的职位。我当时感到很荣幸，但我知道这是一个双输的提议，所以拒绝了。

In a final effort to right the ship, the venture capitalist fired the new management staff. Ken came back as president, and I took over as vice president of consulting. But the drain on capital had gone too far and Optima was shuttered within six months. Except for a few “insider” sales, we never delivered the Design Machine to the CASE tool market. Ken resigned, and in a last-ditch effort to salvage something out of the debacle, the venture capitalist offered me the president/CEO position. I was momentarily flattered, but knew it was a lose–lose proposition, and declined.

KOA/Optima 的故事是我在创业公司大熔炉中冒险的经历，当时我面临着来自资金来源的巨大压力。创业公司过去和现在都有很多失败的方法，而成功的途径也很少。但很难不去争取那枚闪亮的金戒指。最后，我的创业成绩是 0 胜 2 负。幸运的是，失败也让我学到了一些东西。

The KOA/Optima story was my venture into the cauldron of start-up companies faced with lots of pressure from their funding sources. There were, and are, many ways to fail as a start-up and a few avenues for success. But it’s hard not to reach out for the shiny golden ring. In the end, my start-up score was 0 wins, 2 losses. Fortunately, with the losses came a bit of learning.

对于 CASE 工具供应商来说，技术变革（客户端-服务器、互联网和面向对象）需要快速增加投资资金。结合其他问题，第一轮 CASE 工具失败了。但他们也为下一轮软件开发工具建立了框架。

For CASE tool vendors, the technology changes—client-server, Internet, and object orientation—required rapid escalation in investment funds. In combination with the other issues raised, the first round of CASE tools flamed out. But they also established a framework for the next round of software development tools.

在 Optima 之后的十年的最后几年，我为 McDonald Douglas Automation 工作，教授和咨询其 STRADIS 方法。我从 DSSD 到 STRADIS 的过渡很简单：图表发生了变化，但底层方法论是相似的。我教授需求、设计、STRADIS 概述和项目管理的组合。我还签约教授系统思维研讨会。在“敏捷之根”时代，这种系统思维基础对我的思维方式从巨型方法论转变为快速、适应性以及最终的敏捷开发产生了重大影响。

After Optima, during the final couple years of the decade, I worked for McDonald Douglas Automation, teaching and consulting on its STRADIS methodology. My transition from DSSD to STRADIS was straightforward: The diagrams changed, but the underlying methodologies were similar. I taught combinations of requirements, design, STRADIS overviews, and project management. I also contracted to teach a systems thinking workshop. In the Roots of Agile era, this grounding in systems thinking was influential in shifting my mindset from Monumental Methodologies to rapid, adaptive, and eventually agile development.

时代观察

Era observations

结构化时代推动了软件工程的极乐世界——为开发过程带来纪律和控制，成为一门工程学科。管理理论牢牢地停留在命令控制模型中，管理者对软件项目缺乏控制感到不满。结构化是当时的好名字，结构化方法广受欢迎。当然，在实践中，人们说的比做的多，因为人们认为他们画了几张图就结构化了——就像说“我们现在很敏捷，因为我们每天都会站起来，制定冲刺计划。”

The Structured era pushed hard toward the nirvana of software engineering—to bring discipline and control to the development process, to be recognized as an engineering discipline. Management theory was firmly stuck in the command-control model, and managers were not happy with the lack of control over software projects. Structured was a good name for the times, and structured methodologies appealed widely. Of course, in practice, there was more saying than doing as people contended they were structured because they drew a couple of diagrams—much like saying, “We are now agile because we do daily stand-ups and Sprint plans.”

在这个时代即将结束时，一些新兴的声音开始谈论一种更加以人为本的管理观，这种观点最终发展成为共情时代的开始。杰拉尔德（杰瑞）温伯格出版了经典著作《计算机编程心理学》（1971 年）。1998 年出版了银周年纪念版时，我写信给杰瑞，向他表示祝贺，并告诉他我还有一本 1971 年出版的原版。汤姆·德马科和蒂姆·利斯特于 1987 年出版了《人件：高效的项目和团队》。几十年来， 《人件》一直是畅销书。

Toward the end of this era, some emerging voices spoke to a more people-centric view of management that blossomed into the beginning of the Empathy Age. Gerald (Jerry) Weinberg had published the classic The Psychology of Computer Programming (1971). When a silver anniversary edition was published in 1998, I wrote to Jerry, congratulating him and saying I still had an original copy of the 1971 book. Tom DeMarco and Tim Lister published Peopleware: Productive Projects and Teams in 1987. Peopleware continued to be a top seller for decades.

管理理论先驱包括道格拉斯·麦格雷戈，他著有《企业的人性化一面》（1960 年）。他的书将关于个人动机的 X 理论和 Y 理论引入管理理论。20 世纪 90 年代，商业和技术更加重视人性化。

Management theory pioneers included Douglas McGregor, who wrote The Human Side of Enterprise (1960). His book introduced Theory X and Theory Y, about what motivated individuals, into management theory. More emphasis on the people side of business and technology would emerge in the 1990s.

正如往常一样，一个时代的成功和失败为下一个时代奠定了基础。CASE 工具表明需要更好的工具，但同时也表明构建这些工具的挑战。结构化图表的泛滥凸显了标准化的必要性，从而催生了 UML。更快、更可靠的连接愿景开启了互联网时代。

As always happens, the successes and failures of one era form the base for the next. CASE tools signaled the need for better tools, but also the challenges of building them. The plethora of structured diagrams underlined the need for standardization, giving rise to UML. Visions of faster, more reliable, connectivity ushered in the Internet era.

在持续的变革之战中，无论是创造还是销售新产品或新方法，都需要敢于打破常规。令人着迷的是，这些特征最具代表性的例子之一就诞生于这一时期。

In the ongoing battle for change, both creating and selling a new product or methodology require adventurous nonconformity. It is fascinating that one of the most iconic examples of these traits was produced during this period.

苹果公司制作了历史上最著名的电视广告——1984 年超级碗广告，介绍了 Macintosh 电脑。这则广告的概念基础是乔治·奥威尔的反乌托邦小说《1984》，其中人们盲目服从老大哥。身着黑衣的人群将群众描绘成雌雄同体的机器人。色彩斑斓的女主角突破了一道屏障，介绍了 Mac 和苹果公司不墨守成规、充满力量的个性。这也是对 IBM 的一次毫不掩饰的嘲讽。这则强有力的广告让我久久不能忘怀。

Apple created the most famous television ad in history—its 1984 Super Bowl ad introducing the Macintosh computer. The ad’s conceptual foundation was George Orwell’s dystopian book 1984, in which people mindlessly obey Big Brother. The black-clad crowd portrays the masses as androgynist automatons. The colorful heroine breaks through a barrier introducing both the Mac and Apple’s nonconformist and empowered personality. It was also a not-so-subtle swipe at IBM. The powerful ad stuck with me for a long time.

時代總觀

Era overview

Roots 时代在很多方面都具有变革性。软件开发方法开始用确定性、优化、瀑布方法应对这些问题。互联网带来了令人兴奋的新可能性。管理层开始改变与员工的关系。新的软件开发先驱应运而生。这是一个繁忙的十年，本章反映了这一业务。我将 Roots 时代分为三个时期，这些划分与我的思维演变直接相关。图 4.1显示了这些 Roots 时期，它们代表了我自己（而不是行业）的转型。

The Roots era was transformative in several ways. Software development methodologies began to react to the concerns with deterministic, optimizing, waterfall methodologies. The Internet ushered in exciting new possibilities. Management began to transform relationships with employees. New software development pioneers emerged. It was a busy decade, and this chapter reflects that business. I’ve divided the Roots era into three periods, with the divisions being related directly to the evolution of my thinking. Figure 4.1 shows these Roots periods that identify my own (not industry) transformation.

除了我的结构化到自适应的历程之外，本章还介绍了几个客户参与情况，这些情况证实并扩展了我的思想，包括撰写我的第一本书、我对复杂自适应系统 (CAS) 理论的尝试，以及研究其他新兴的敏捷方法。

In addition to my structured to adaptive journey, the chapter profiles several client engagements that confirmed and extended my thinking, writing my first book, my foray into complex adaptive systems (CAS) theory, and taking a look at other emerging agile methodologies.

我记得 20 世纪 90 年代是一个相对和平与繁荣的十年——美国和苏联结束了长达数十年的冷战，而互联网的兴起开启了通讯的关键新时代，影响了商业和个人互动。这是比尔·克林顿、嘻哈音乐和极端党派政治种子的十年。《侏罗纪公园》取代了 1970 年的《大白鲨》，成为最可怕的自然类电影野兽。

I remember the 1990s as a decade of relative peace and prosperity—the United States and Soviet Union ended the decades-long Cold War, while the rise of the Internet ushered in a pivotal new era of communications, impacting both business and personal interactions. It was the decade of Bill Clinton, hip hop music, and the seeds of ultra-partisan politics. Jurassic Park ousted the 1970 Jaws as having the scariest nature-related movie beast.

1989 年，我和妻子搬到了盐湖城，她的工作是达美航空的空乘基地经理。我带着行李箱工作，我的基地可以是任何地方。此外，想到住在西部，攀岩和滑雪从长途飞行到开车 40 分钟，这都是我所需要的动力。当户外探险成为日常活动时，我开始看到软件开发和攀岩之间的相似之处。

In 1989, my wife and I moved to Salt Lake City for her job, as manager of the flight attendant base for Delta Air Lines. I worked out of a suitcase, and my home base could be anywhere. Moreover, the thought of living out West, where climbing and skiing went from a long airplane ride to a 40-minute drive, was all the incentive I needed. When outdoor adventures were everyday events, I began to see the analogies between software development and climbing.

技术攀登涉及风险，但保持灵活性可以降低这些风险。攀登计划会随着天气和条件的变化而不断变化。我开始意识到，登山者必须适应山的现实，但对于软件项目，我们期望现实适应我们的计划。这十年开始时，我的攀登和软件开发处于不同的轨道上，但很快它们就开始走到一起了。

Technical climbing involves risks, but those risks can be mitigated by remaining flexible. Climbing plans are constantly shifting as weather and conditions dictate. It began dawning on me that climbers must adapt to the reality of a mountain, yet with software projects, we expected reality to adapt to our plans. I began the decade with my climbing and software development on separate tracks, but they soon began traveling together.

1992 年 6 月，我在一篇题为“软件攀登”的文章中谈到了这种对比，该文章刊登在 Ed Yourdon 的《美国程序员》杂志上。Ed 在杂志的前言中写道：“Jim Highsmith 给我们发了一篇精彩的文章，将软件项目比作登山；我们认为你会喜欢它。”这篇文章表明了我的思维过程的演变，从将方法论视为一个预测过程，到将其视为一个“受控制”的过程，就像登山计划会根据地形和天气状况的评估不断变化一样。

In June 1992, I wrote about this juxtaposition in an article titled “Software Ascents,” for Ed Yourdon’s American Programmer journal. In his introduction to the journal, Ed wrote, “Jim Highsmith sent us a wonderful article comparing software projects to mountain climbing; we think you will enjoy it.” This article indicated my evolving thought process, from thinking about methodology as a predictive process to one that was “steered,” just as climbing plans changed constantly from assessing the terrain and weather conditions.

企业逐渐被诸如全面质量管理 (TQM) 和业务流程再造 (BPR) 等规范性实践所吸引，但对团队的兴趣也日益浓厚，这一点从 团队智慧（Katzenbach，1992）和组织学习（Senge，1990）。BPR 倡导者相信自动化、确定性流程，并将人视为机器中的齿轮。此外，精益原则和实践在精简制造方面非常有效，并被转化为知识工作，包括软件开发。

Companies were being drawn to prescriptive practices like total quality management (TQM) and business process reengineering (BPR), but there was also a growing interest in teams, as evidenced by the success of The Wisdom of Teams (Katzenbach, 1992), and in organizational learning (Senge, 1990). BPR advocates believed in automated, deterministic processes and considered people to be cogs in the machine. In addition, Lean principles and practices, effective in streamlining manufacturing, were translated into knowledge work, including for software development.

RAD 的结构化方法

Structured methods to RAD

“耗时太长，成本太高，不能满足我们的需求”，高管们在试图响应市场需求时如此哀叹他们的 IT 软件项目。这十年伊始，我在结构化技术和瀑布方法（如 DSSD 和 STRADIS）方面从事独立咨询和教学工作坊。2^十年结束时，我放弃了这两者。为了响应高管的求助，软件开发人员开始尝试 RAD 方法。我带领技术团队开展了一个项目，制作 STRADIS 的 RAD 版本——我们注定失败的方法是到处删除文档和流程要求。但必须进行根本性的改变，因为这些早期为满足日益增长的更快开发呼声而做出的尝试既没有修改瀑布生命周期，也没有彻底改变思维方式。

“Take too long, cost too much, do not meet our needs,” executives lamented about their IT software projects, as they tried to respond to market demands. I began this decade doing independent consulting and teaching workshops in structured techniques and waterfall methodologies such as DSSD and STRADIS.² I ended the decade having abandoned both. In response to executive cries for help, software developers began experimenting with RAD methodologies. I led the technical team on a project to produce a RAD version of STRADIS—our ill-fated approach was to remove document and process requirements here and there. But a fundamental change was needed, as these early attempts to address the growing clamor for faster development contained neither a revision to the waterfall life cycle nor any radical change in mindset.

2.例如，STRADIS 由七本大笔记本组成，其中极其详细地定义了流程、文档和设计图表。

2. STRADIS, for example, consisted of seven large notebooks that defined processes, document, and design diagrams in excruciating detail.

我开始质疑传统的开发方法，部分原因是它不适合我的工作方式。我的思绪回到了狂野西部时代，享受着同时担任多个角色（分析师、程序员、测试员）的乐趣，这些角色不使用规定性流程，而是采用迭代流程。

I began to question the conventional approach to development, in part because it wasn’t the way I worked. My thoughts returned to the Wild West days and the enjoyment of having multiple roles—analyst, programmer, tester—that didn’t use a prescriptive process but rather an iterative one.

20 世纪 80 年代末发生的一件事加深了我对瀑布式生命周期和文档的怀疑。当时，我在密苏里州圣路易斯教授 STRADIS 需求定义和设计课程。这门为期 5 天的课程向公众开放，在酒店会议室进行。当时的课程后勤工作需要体力和脑力。

An incident from the late 1980s fueled my skepticism of the waterfall life cycle and documentation. I was teaching a STRADIS requirements definition and design course in St. Louis, Missouri. This 5-day class was open to the public and conducted in a hotel meeting room. The class logistics in those days required both physical and mental strength.

首先，教师必须检查设置。其次，你必须找到学生的练习册。酒店工作人员经常坚持说练习册不在那里，我坚持说有，然后搜查了邮件室才找到。接下来是检查投影仪是否可用并且正常工作。当时我们使用 8½- × 10½ 英寸的透明胶片（薄箔塑料片）来显示课堂信息。我有两个 3 英寸的笔记本活页夹，里面塞满了“箔纸”，我把它们放在一个大皮包里。包括我的其他教师用具，它很重。便携式电脑用一台很重的电脑（我的 Compaq 便携式电脑）取代了沉重的包。但有一段时间，我不得不同时携带这两台电脑，因为便携式电脑的可靠性值得怀疑，而且你永远不知道酒店（或客户）是否有兼容的投影仪或合适的连接线。那时，你就可以开始考虑教课了。

First, the instructor had to check the setup. Second, you had to find the student workbooks. Often the hotel staff insisted the workbooks were not there, I insisted they were, and a search of the mail room found them. Next was checking that an overhead projector was available and working. In those days we used 8½- × 10½-inch transparencies (thin foil plastic sheets) for class information display. I had two 3-inch notebook binders crammed with “foils” I carried in a large leather bag. Including my other instructor paraphernalia, it was heavy. Portable computers replaced the heavy bag with a heavy computer, my Compaq luggable. But for a time, I had to carry both because the reliability of the luggable was suspect and you never knew if the hotel (or client) would have a compatible projector or the right hookup cables. At that point, you could start thinking about teaching the class.

在 STRADIS 课堂上，十几位学员在墙上贴满了数据流程图、结构图和实体关系图。最后一天，我问他们：“从所有这些图表中，你们可以看出如何编码，对吗？”房间里充满了茫然的表情。他们不知道！当我在黑板上画出图表和 COBOL 程序各部分之间的联系时，灯亮了。文档，甚至不是图形文档，足以传达个人在下一阶段工作中所需的所有信息。

In the STRADIS class, a dozen participants filled the walls with data flow diagrams, structure charts, and entity-relationship diagrams. On the last day, I queried them, “From all these diagrams you can see how to code it, correct?” The room filled with blank stares. They didn’t know! On the board, as I drew connections between the diagrams and the parts of a COBOL program, the lights went on. Documentation, not even graphic documentation, was enough to convey all the information required by individuals in the next phase of work.

我知道负责代码维护的程序员总是阅读代码以了解情况，因为他们知道文档会过时。包括经理在内的每个人都意识到了这种脱节，但仍然继续走他们经典的道路。

I knew programmers doing code maintenance always read the code for understanding because they knew documentation would be outdated. Everyone, including managers, recognized this disconnect, but continued along their classic path.

在本世纪初，IT 客户并不满意，我也不满意。是时候做出改变了。

At the beginning of the decade, IT customers were not happy, and I wasn’t happy. It was time for a change.

大约在那个时候，Larry Constantine 打电话给我。他被要求帮助 Amdahl（一家大型计算机制造商）开发一种 RAD 方法。他因为有冲突（他正在为 IBM 提供咨询）而拒绝了，并问我是否有兴趣。这成为了我进入 RAD 世界的契机，也是我与 Sam Bayer 长达数十年的友谊的开始。

Around that time, Larry Constantine called me. He had been asked to help Amdahl (a mainframe computer manufacturer) develop a RAD method. He had declined because of a conflict (he was consulting with IBM) and asked if I was interested. This turned out to be my entrance into the RAD world and the beginning of a decades-long friendship with Sam Bayer.

Amdahl 的问题是销售周期太长（有时长达 18 个月），因为客户不了解他们的产品。Sam 是寻求帮助的营销经理。我接受了工程和商业方面的双重教育，而 Sam 则拥有营销方面的双重背景和化学博士学位（谁知道化学对营销来说是很好的培训）。我们很快成为了朋友和同事。Sam 正在为一款名为 Huron 的大型机 RAD 软件工具寻找营销策略。

Amdahl’s problem was a long (sometimes 18 months) sales cycle because clients didn’t understand their product. Sam was the marketing manager looking for help. Much as I had a two-pronged education in engineering and business, Sam had a double background in marketing and a PhD in chemistry (who knew chemistry was good training for marketing). We quickly became friends and colleagues. Sam was searching for a marketing strategy for a mainframe RAD software tool, named Huron.

Sam 希望缩短销售周期，并向潜在客户展示如何快速从该产品中获得价值。鉴于大型机软件价格昂贵，销售起来并不容易。Sam 和我创建了一种迭代 RAD 方法，然后用它在四周内构建了一个客户的应用程序。我们去了客户那里，组建了一个由各种 Amdahl 和客户人员组成的小团队，每周交付可用的软件，并每周五进行“客户焦点小组”来展示向客户代表介绍新功能并获取反馈。四周后，我们将交付一个完整的应用程序，统计数据显示生产率和质量提高了数倍。但我们的项目经常遇到根深蒂固的组织障碍。在纽约市的一家银行，我们在四周内交付了银行需要的一款工作应用程序，但 IT 运营部门却告诉他们，他们大约六个月后才能安装该应用程序！这是未来障碍的前兆。Sam 和我进行了数十个这样的项目，从未失败过。

Sam wanted to shorten the sales cycle and show potential customers how to quickly derive value from this product. Given the mainframe software’s hefty price, it had not been an easy sell. Sam and I created an iterative RAD methodology, then used it to build a customer’s application in four weeks. We went to a customer’s location, assembled a small team that included a variety of Amdahl and customer people, delivered working software every week, and conducted “customer focus groups” every Friday to demonstrate features to customer representatives and get feedback. At the end of four weeks, we would deliver a complete application with statistics that showed multiple times better productivity and quality. But our projects often ran into trouble with entrenched organizational barriers. In one New York City bank, we delivered a working application the bank needed in four weeks, only to then be told by the IT operations department they would be able to install the application in about six months! This was a precursor of barriers to come. Sam and I conducted dozens of these projects and never had a failure.

1994 年 6 月，Sam 和我在《美国程序员》杂志上发表了一篇题为“激进软件开发”的文章（Bayer and Highsmith，1994 年）。3 ^Sam后来成为 Corevist 的创始人兼首席执行官，该公司在整个公司范围内采用了敏捷实践。

In June 1994, Sam and I published an article in American Programmer magazine titled “RADical Software Development” (Bayer and Highsmith, 1994).³ Sam later became the founder and CEO of Corevist, which used agile practices throughout the company.

3.回顾本书的文章时，我注意到作者简介中包含我的第一个电子邮件地址 — 73030.432@compuserv.com。

3. Reviewing this article for this book, I noticed the author bio included my first email address—73030.432@compuserv.com.

我试图展现这十年来软件方法论的演变，就像它发生在我身上一样。它始于与 Sam 一起工作的近两年。我希望我能数清楚我们与客户合作的 RAD 项目的数量，但我没有——但我猜有几十个。如果你从事一个为期一年的项目（当时并不罕见），你就可以练习一次特定的方法。如果你做 20 个为期一个月的项目，你就可以练习每种方法 20 次。无论 Sam 和我从每个项目中学到什么，我们都将运用到未来的工作中。

I’ve tried to unfold this decade’s software methodology evolution as it unfolded for me. It began with nearly two years working with Sam. I wish I’d kept count of the number of these RAD projects we undertook with clients, but I didn’t—but I guess it was several dozen. If you work on a one-year project (not unheard of then), you get to practice specific methods one time. If you do 20 one-month projects, you get to practice each method 20 times. Whatever Sam and I learned from each project, we carried into our future work.

在本世纪初，我读到了关于 RAD 的文章，但最初认为它只是一时的热潮。随着 Sam 和我一起在这些短期 RAD 项目上工作了几年，我开始意识到 RAD 的潜力。了解这些方法的工作原理、每周向客户展示运行中的功能、在小型协作团队中工作、使用一周迭代——这一切都开始凝聚在一起。我担心的一个问题是，许多 RAD 支持者似乎放弃了经过验证的技术实践。在刚刚提到的 RADical 文章中，Sam 和我写道：“一些快速开发方法的支持者将它们视为软件工程技术的替代品。……但放弃我们已经学到的关于构建高质量系统的知识并不是答案。”

At the start of this decade, I read about RAD, but initially viewed it as a fad. As Sam and I worked together for several years on these short RAD projects, I began to realize the possibilities. Seeing how the methods worked, presenting running features to the customers every week, working in small collaborative teams, using one-week iterations—it all began to gel. One of my concerns was that many RAD proponents seemed to abandon proven technical practices. In the RADical article just mentioned, Sam and I wrote, “Some proponents of rapid development methods see them as a replacement for software engineering techniques. … But abandoning what we have learned about building high-quality systems was not the answer.”

微软

Microsoft

20 世纪 90 年代初，我开始在华盛顿州雷德蒙德的微软公司教授为期五年的研讨会，当时该公司约有 4,000 名员工。虽然我也教授过一些项目管理研讨会，但我的主要工作是工作是一门名为“软件质量动力学”的课程。杰里·温伯格曾向微软介绍过这个研讨会，但在短暂的争吵之后，他邀请了与我联系的林恩·尼克斯来教授持续进行的研讨会。林恩负责大部分项目管理，我负责软件质量课程。杰里的质量课程基于他的四卷本《软件质量动力学》系列中的材料，教起来很有趣（温伯格，1994 年）。杰里在设计游戏和模拟方面有着独特的能力——纸牌屋、珠子游戏——既能激发学习兴趣，又能给研讨会参与者带来乐趣。

The early 1990s also began my five-year stint teaching workshops at Microsoft in Redmond, Washington, which had about 4,000 employees at the time. Although I taught a few project management workshops, my primary work was a course called Software Quality Dynamics. Jerry Weinberg had introduced this workshop to Microsoft but after a brief kerfuffle, invited Lynne Nix, who contacted me, to teach ongoing workshops. Lynne handled most of the project management and I handled the software quality courses. Jerry’s quality course was based on the material in his four-volume Software Quality Dynamics series and was a joy to teach (Weinberg, 1994). Jerry had a unique ability to design games and simulations—House of Cards, Bead Game—that both inspired learning and were fun for workshop participants.

纸牌屋游戏让参与者直接练习团队动态，使用 80 列打孔卡（它们变得很难找到）来建造一个结构。高度、顶部和底部的直径以及美观度都有规格和分数。练习进行到一半时，我会从一个团队中挑选一个人，将他分配到另一个团队。在介绍新团队成员时，我会随口提到这个人在建造房屋方面享有盛誉。我没有告诉他们的是，虽然尺寸有分值，但每个团队的得分计算方式都不同！一个团队从底部的大尺寸和顶部的窄尺寸获得分数，而另一个团队的得分则使用相反的标准。中间到达的新团队成员一直在使用不同的计分表，因此，他们当然会立即尝试更改设计，从而产生冲突。游戏结束后，我为每栋建筑分配了一个美观度分数。哎呀！参与者总是对我的美观度分数发出嘘声，因为他们抱怨我的偏见、不公平和武断的分数。我的回答是：“您不觉得您的客户在评价您的产品时经常是武断的吗？”

The House of Cards game gave participants direct practice in team dynamics, by using 80-column punch cards (they became hard to find) to build a structure. There were specs and points for height, diameter of the top and bottom, and aesthetics. Halfway through the exercise, I would take a person from one team and assign them to another. While introducing the new team member, I would casually mention this person had a great house-building reputation. What I didn’t tell them was, although the dimensions had point values, each team’s scoring calculation was different! One team gained points from a large dimension on the bottom and a narrow one on top, while another team’s score used the opposite rubric. The new team member arriving in the middle had been working on a different scoring sheet, so, of course, they immediately tried to change the design, setting up conflict. When the game was over, I assigned an aesthetics score to each building. Yikes! There was always booing at my aesthetics scores as the participants complained about my bias, unfairness, and arbitrary scores. My reply: “Don’t you think your customers are often arbitrary in their assessment of your products?”

这个游戏很有趣，让每个人都从椅子上站起来，大声讨论问题。练习时间的最后 30 到 35 分钟用于讨论参与者学到的一系列问题。大部分讨论都集中在人与人之间的互动上。

The game was fun and got everyone up from their chairs, discussing issues loudly. The last 30 to 35 minutes of the exercise time was spent discussing a range of questions about what participants had learned. Much of the discussion centered on people and their interactions.

我已经使用结构化方法和瀑布式生命周期十年了，我最初的想法是微软做错了一切。我的下一个想法是“但他们非常成功。”瀑布式生命周期的追随者专注于前端需求和设计，认为编程和测试主要是“机械”活动，而微软则扭转了重点，认为创造性的部分是编程和测试。随着我在接下来的几年里了解了微软的流程，我确信 Sam Bayer 和我正在开发的 RAD 方法将具有可扩展性。

Having a decade of working with structured methods and waterfall life cycles, my initial thought was that Microsoft was doing everything wrong. My next thought was “But they are extremely successful.” While waterfall life cycle adherents focused on the front-end requirements and design, believing programming and testing were mostly “mechanical” activities, Microsoft reversed the emphasis, believing the creative parts were programming and testing. As I learned about Microsoft’s processes over the next several years, I became convinced the RAD methodology Sam Bayer and I were developing would scale.

从 RAD 到 RADical

RAD to RADical

RADical 软件开发是我版本的 RAD，两者的区别不仅仅是名字更可爱。但我认为我当时并没有理解这些差异的后果。RAD 是关于速度的。RADical 是关于价值、质量、速度、领导力和协作——你可以称之为“专业 RAD”。我们不仅需要速度，还需要在多个方面做到 RADical。在我们的 RADical 文章（Bayer 和 Highsmith，1994 年）中，Sam 和我确定了这种方法的五个关键方面：

RADical Software Development was my version of RAD, and the difference was more than a cuter name. But I don’t think I understood the ramifications of the differences then. RAD was about speed. RADical was about value, quality, speed, leadership, and collaboration—you might call it “professional RAD.” We didn’t just need speed, we needed to be RADical in several dimensions. In our RADical article (Bayer and Highsmith, 1994), Sam and I identified five key aspects of this methodology:

• 生命周期必须从静态的、面向文档的过程转变为动态的、进化的、面向产品的过程。

• The life cycle must transform from a static, documentation-oriented process to a dynamic, evolutionary, product orientation.

• 项目管理需要利用短“时间盒”技术。

• Project management needed to utilize short “timebox” techniques.

• 需要一个进化的^{4生命周期。}

  4、在这期间，我使用“进化”这个词，而不是“迭代”。

• An evolutionary⁴ life cycle was needed.

  4. During this period, I used the word evolutionary rather than iterative.

• RADical 需要专门的团队。

• RADical required dedicated teams.

• 良好的工程技能至关重要。

• Good engineering skills were essential.

我们在文章中没有使用“思维模式”这个词，但 Ed Yourdon 在引言中使用了这个词。这篇文章的最后一句话预示着未来，尽管它花了十年才成为现实：“如果信息技术是重组公司的关键之一，那么现在是时候认真考虑重组工程师了。”

We didn’t use the word “mindset” in the article, but Ed Yourdon did in his introduction. The last sentence in this article signaled the future, though it took a decade to become reality: “If information technology is one key to reengineering corporations, it is time to think seriously about reengineering the engineers.”

波特兰抵押贷款软件

Portland Mortgage Software

早期客户波特兰抵押贷款软件公司位于俄勒冈州波特兰市。该公司开发的抵押贷款处理软件在全美 50 个州使用，每个州的抵押贷款处理规定都有或大或小的差异。此外，联邦抵押贷款规定必须纳入软件中。该公司为大型金融公司销售一套产品，为小型金融公司销售单个产品。

Portland Mortgage Software, an early client, was located in Portland, Oregon. It developed mortgage processing software used in all 50 states, each of which had minor to major variations in its mortgage processing regulations. In addition, federal mortgage regulations had to be incorporated into the software. The company sold a suite of products for large financial companies, and individual products for smaller ones.

就像一个典型的组织一样，每个专业（法律、会计和软件开发）都有自己的组织孤岛，当然，它们位于大楼的不同区域。这些孤岛之间的沟通有很大的改进空间。

As in a typical organization, each specialty—legal, accounting, and software development—had its own organizational silos, in different sections of the building, of course. Communications between the siloed groups left much room for improvement.

我的客户请我帮助提高这些部门的交付绩效。除了让他们参与快速开发流程外，我还建议他们重组为跨职能产品组，并以团队的形式坐在一起。在变革进行了一段时间后，我问开发经理新的组织和流程进展如何。

My client asked me to help improve these departments’ delivery performance. In addition to engaging them in a rapid development process, I suggested they reorganize into cross-functional product groups—and sit together as teams. After the changes had been under way for a while, I asked the development manager how the new organization and process were going.

他说道：“我们能够比以前更快地推出更好的产品。”

“We are getting better products out faster than before,” he said.

“有什么不好的吗？”我问道。

“Any negatives?” I asked.

“嗯，”他回答道，“产品团队偶尔会抱怨他们彼此之间沟通不够。”

“Well,” he replied, “the product teams complain occasionally that they don’t communicate with each other enough.”

这让我想起一句古老的系统理论：“只希望你的问题解决方案不会产生比最初更多的问题。”改变总会有后果，有好的后果，也有不好的后果。

This reminds me of an old systems theory saying, “Just hope your problem solution doesn’t create more problems than you had in the first place.” There are always consequences of change, both for good and for not so good.

与 Portland Mortgage Software 合作让我更加坚信，解决方案有无数种组合——流程、组织、绩效衡量标准——每个组织都不同。我的想法从“一刀切”的宏大方法转变为“一刀切”。

Working with Portland Mortgage Software confirmed my belief that solutions come in myriad combinations—process, organization, performance measures—that differ for each organization. My thinking continued transforming from a monumental approach of “one size fits all” to “one size fits one.”

这次合作加深了我对跨职能协作团队作为核心软件交付组织的理解和承诺。由于我的客户是一家软件公司，我了解了交付的产品视角。

This engagement furthered my understanding of, and commitment to, cross-functional, collaborative teams as the core software delivery organization. As my client was a software company, I learned about a product view of delivery.

信息技术

Information technology

随着我 RAD 工作的进展，技术也在飞速发展。万维网于 1990 年推出，同年 Windows 3.0 推出，Mosaic 浏览器于 1993 年推出，亚马逊于 1994 年作为在线书商出现，谷歌的搜索引擎于 1998 年首次亮相。Windows 进行了重大升级，升级到 95 版。Linus Torvalds 推出了 Linux，引发了开源软件运动。由于 Windows 和 Microsoft Office Suite 的结合，Windows 开始抢占 IT 市场的大块份额。后者挤占了单个应用程序的市场——Lotus、WordPerfect 和 Notes 都在 90 年代末陷入困境。

As my work with RAD was progressing, technology was advancing rapidly. The World Wide Web was introduced in 1990, Windows 3.0 the same year, Mosaic’s browser in 1993, Amazon appeared as an online bookseller in 1994, and Google’s search engine debuted in 1998. Windows had a major upgrade to version 95. Linus Torvalds introduced Linux, which set off the open-source software movement. Windows began grabbing huge chunks of the IT market because of the combination of Windows and the Microsoft Office Suite. The latter crowded out the market for individual applications—Lotus, WordPerfect, and Notes all floundered by the end of the decade.

互联网为企业和个人的生活带来了难以想象的连通性，推动了 CompuServe 和亚马逊等新企业的成功，并开启了人与人之间互动的时代，并有望呈指数级增长。连通性推动了根本性变革精通计算机的企业家取代了那些努力理解网络世界的传统企业。

The Internet brought unimagined connectivity to businesses and individuals’ lives, enabling the success of new businesses like CompuServe and Amazon, and ushered in the person-to-person interaction era, which was poised to grow exponentially. The connectivity drove fundamental changes as computer-savvy entrepreneurs eclipsed traditional businesses struggling to make sense of the cyberworld.

面向对象编程 (OOP) 的发展和进入主流发生在 20 世纪 90 年代，为 20 世纪 80 年代的过程式语言 (COBOL) 提供了替代方案。面向对象编程的创始人 Alan Kay（他在 20 世纪 60 年代创造了这个名字）认为面向对象编程具有适应性和对变化的弹性优势。Smalltalk、Java 和 C++ 等面向对象编程语言的支持者在这个时代争夺霸主地位。三种技术——具有用户友好图形用户界面 (GUI) 的 Windows 和 Mac、可通过新推出的浏览器访问的互联网连接以及面向对象编程——激励人们转变软件开发方式。

The evolution of object-oriented programming (OOP) and its movement into the mainstream occurred during the 1990s, providing an alternative to the procedural languages (COBOL) of the 1980s. Alan Kay, the originator of OOP (who coined the name back in the 1960s), thought OOP provided benefits of adaptability and resilience to changes. Proponents of OOP languages such as Smalltalk, Java, and C++ battled for supremacy during this era. Three technologies—Windows and Macs with their user-friendly graphical user interface (GUI), connectivity via the Internet accessible with newly minted browsers, and OOP—created incentives to pivot software development.

在这十年中，我的客户既有 Portland Mortgage Software 这样的软件公司，也有 Nike 这样的大型 IT 组织（本章后面将详细介绍 Nike）。显然，我需要了解 IT 组织面临的问题以及他们如何尝试解决这些问题。各公司正在尝试各种解决方案来解决“耗时太长、成本太高、无法满足我们的需求”的问题。虽然有少数公司尝试了 RAD，但大多数公司仍坚持使用传统方法，但人们对 RAD 的兴趣日益浓厚，这表明现状需要更新。与任何方法一样，对 RAD 的批评也层出不穷——他们在一点上是对的。RAD 开发人员认为应用程序的淘汰速度越来越快，因此重点是速度而不是质量，因为系统退役指日可待。不幸的是，这种假设是错误的，只会增加软件维护的麻烦。

During this decade, my clients were both software companies like Portland Mortgage Software and large IT organizations in companies like Nike (more on Nike later in the chapter). Obviously, I needed to keep up with the problems IT organizations were facing and how they were attempting to solve those problems. Companies were trying out a variety of solutions to their “take too long, cost too much, do not meet our needs” problem. While a few tried RAD, most stuck to traditional methodologies, but the rising interest in RAD indicated the status quo needed refreshing. As with any approach, critics of RAD abounded—and they were right on one point. RAD developers assumed applications were experiencing faster and faster obsolescence, so the emphasis was on speed rather than on quality, since system retirement was just around the corner. Unfortunately, this assumption was wrong and just increased software maintenance woes.

加剧 IT 问题的是，人们对技术债务的理解日益加深，但仍然不够深入。由于总经理和 IT 经理都沉迷于可预测性和严谨性，他们忘记了有形的东西（如小部件）与无形的可塑性的东西（如软件）之间的根本区别。小部件一旦从工厂生产出来，就不会改变。软件可以改变，而且确实会改变。这种短视导致了严重的技术债务问题，使可塑性软件变成了一团乱麻，成本高昂的烂摊子。

Adding to the problems in IT was a growing, but still feeble, understanding of technical debt. As both general and IT managers became enthralled with predictability and rigor, they forgot the fundamental difference between tangible things like widgets and intangible and malleable things like software. Once a widget emerges from a factory, it doesn’t change. Software can and does. This myopia gave rise to the serious issue of technical debt, turning malleable software into a muddled, high-cost mess.

为了解决 IT 领域的所有这些问题，备受推崇的策略包括外包和安装企业软件包。虽然我没有参与这两个领域，但它们确实影响了 IT 组织，并继续使它们偏向于规范性解决方案。此外，厌倦了等待的业务用户开始采用终端用户计算解决方案。

To solve all these problems within the IT realm, highly touted strategies included outsourcing and installing enterprise package software. While I was not involved with either of these areas, they certainly impacted IT organizations and continued to bias them toward prescriptive solutions. In addition, business users, tired of waiting, began to adopt end-user computing solutions.

20 世纪 90 年代，各公司对此的反应部分是遵循我总结为“把一切都运到印度”的口号。这一趋势的一部分是将软件维护和大型开发项目的编程阶段外包。软件外包背后的假设是，只需最少的沟通即可完成技能要求较低且成本较低的编程。由于印度公司急于推广其对严格能力成熟度模型 (CMM) 标准的遵守，许多外包都是基于可预测性和规范性做法的错误前提^。5

In the 1990s, companies responded in part by following the mantra I would summarize as “Ship everything to India.” One part of this trend was to offshore software maintenance and the programming phase of large development projects. The assumptions behind software outsourcing were that less skilled and less expensive programming could be accomplished with minimal communication. Much outsourcing was based on the false premises of predictability and prescriptive practices, as Indian firms rushed to promote their adherence to strict Capability Maturity Model (CMM) standards.⁵

5.能力成熟度模型 (CMM) 是软件工程研究所的产品。CMM 促进了学习，但学习却淹没在用户为达到“成熟度”而必须执行的大量文档和流程中。我不会在本书中深入讨论 CMM 和 CMMI（I = 集成）之间的区别。

5. The Capability Maturity Model (CMM) was a product of the Software Engineering Institute. The CMM promoted learning, which got lost in the blizzard of documentation and processes users had to implement to gain levels of “maturity.” I won’t get into the difference between CMM and CMMI (I = integration) in this book.

第一代运营业务软件现在笨重且过时。当公司寻求更新其陈旧的遗留系统时，他们面临着两个艰难的选择 - 内部构建或购买软件包。这两个选择都很昂贵且有风险，但许多公司选择购买和安装大型企业资源规划 (ERP) 系统，后来又购买客户关系管理 (CRM) 系统。ERP 和 CRM 实施分别需要数年时间，并且通常由大型咨询公司管理。外包和实施大型软件包软件应用程序使 IT 团队失去了在即将到来的互联网动荡中所需的专业知识。在这些多年的实施项目中，互联网爆发，引发了返工需求，并导致了将这些运营系统与外部客户连接起来的笨拙方式。像 Sam Bayer 的 Corevist 这样的小公司通过为 ERP 系统提供不笨重的面向客户的附加解决方案而蓬勃发展。

First-generation operational business software was now clunky and outdated. As companies sought to modernize their aging legacy systems, they faced two daunting choices—build them inhouse or purchase packages. Both options were expensive and risky, but many companies opted to buy and install large enterprise resource planning (ERP) and later customer relationship management (CRM) systems. ERP and CRM implementations took several years each and were often managed by large consulting firms. Outsourcing and implementation of large, packaged software applications stripped IT teams of the expertise they would need in the coming Internet upheaval. The Internet erupted during these multiyear implementation projects, triggering the need for rework and leading to clunky ways to connect these operational systems with external customers. Smaller companies, like Sam Bayer’s Corevist, thrived by offering un-clunky customer-facing add-on solutions to ERP systems.

推动 RAD 方法发展的因素还催生了一种并行的时尚 — 终端用户计算。用户需求的不断增长、每个人办公桌上都出现了 PC，以及电子表格和 RAD 工具的日益复杂化，这些因素共同促成了终端用户开发，这既有好处，也有重大弊端。这些终端用户应用程序可能速度快、响应迅速。然而，开发复杂电子表格的财务部门分析师很少具备测试技能，因此漏洞就悄然出现。南方银行的一位“生产力”顾问开发了这样一种电子表格，用于为抵押贷款处理服务定价。银行使用了这种电子表格一年，直到有人意识到一个错误导致银行在每笔抵押贷款上都亏损 — 在接下来的 15 到 30 年内都是如此！备份和恢复也是一个大问题，因为 PC 存储不是最简单、最可靠的，在那些日子里。在 20 世纪 90 年代初期，我的备份包括 20 张 3¼ 英寸软盘。猜猜我备份的频率是多少？

The factors that drove RAD methods also fostered a parallel fad—end-user computing. The combination of growing user needs, PCs sprouting on everyone’s desks, and the increasing sophistication of spreadsheets and RAD tools enabled end-user development that had benefits, but also significant downsides. These end-user applications could be fast and responsive. However, an analyst in the finance department developing a complex spreadsheet rarely had testing skill, so bugs crept in. One “productivity” consultant at a Southern bank developed such a spreadsheet for pricing mortgage processing services. The bank used this spreadsheet for a year until someone realized an error ensured the bank lost money on every mortgage—for the next 15 to 30 years of the mortgage’s life! Backup and recovery was also a big issue since PC storage wasn’t the easiest, or the most reliable, in those days. At one point in the early 1990s, my backup consisted of twenty 3¼-inch diskettes. Guess how often I backed up?

电子表格开发人员的同事会复制他们的电子表格并进行修改。用户会在线查找数据并手动将数据输入电子表格。现在，您有四五个版本的电子表格。然后，财务部门经理会联系 IT，要求整合所有电子表格版本、扩展应用程序以适应多个用户、实施安全措施、从操作系统中提取数据以填充电子表格并修复错误。IT 部门的软件开发人员通常没有使用电子表格的经验，而且 IT 部门有其他工作要做，因此对这些请求的典型回应是“你创建它，你修复它”。这种态度并没有为 IT 在业务部门的声誉带来奇迹。

Colleagues of the spreadsheet developers would copy their spreadsheet and typically make their own modifications. Users would look up data online and manually enter the data into the spreadsheet. Now you had four or five versions of the spreadsheet floating around. The finance department manager would then approach IT with a request to consolidate all the spreadsheet versions, scale the application for multiple users, implement security measures, extract data from operational systems to populate the spreadsheet, and fix bugs. Software developers in IT typically didn’t have experience with spreadsheets, and IT departments were deluged with other work, so the typical response to these requests was “You built it, you fix it.” That attitude didn’t do wonders for IT’s reputation in business departments.

对于任何技术或方法，都有一个“最佳点”，可以有效且有益。但也存在最初并不明显的陷阱。作为过去影响现在的一个例子，20 世纪 90 年代的终端用户计算和 2020 年代初使用“低代码”或“无代码”工具之间是否有相似之处？

For any technology, or methodology, there is a “sweet spot” where it can be effective and beneficial. But there are also pitfalls that are not initially obvious. As an example of the past informing the present, are there parallels between the 1990s end-user computing and the early 2020s use of “low-code” or “no-code” tools?

20 世纪 90 年代中后期，互联网的快速发展对通信行业和亚马逊等公司的崛起产生了直接影响。但它也对所有企业产生了持久而重大的影响：

The rapid growth of the Internet in the mid- to late 1990s had an immediate impact on communications and the rise of companies like Amazon. But it also had a lasting, significant impact on all enterprises:

互联网将软件开发的重点从内部业务系统转移到面向外部客户的系统。

The Internet refocused software development from internal business systems to external customer-facing ones.

如今，我们理所当然地可以在线向州政府更新驾照、通过银行在线系统支付账单、通过手机购买股票或在 Twitter 上发布最新言论。以前，客户会致电订单处理人员，然后订单处理人员会将订单输入订单输入系统。然后，在 20 世纪 90 年代，各公司纷纷开发面向客户的应用程序，例如无需人工参与即可处理订单的应用程序。

Today we take for granted our ability to renew driver’s licenses online with state governments, pay bills from our bank’s online system, buy stocks on our cell phones, or post our latest diatribe on Twitter. Previously, customers would call an order-processing person, who would then enter their order into the order entry system. Then, in the 1990s, companies scrambled to build customer-facing applications—for example, those for processing orders without a person in the process.

这种转变是由互联网、图形用户界面以及个人电脑使用范围的扩大和功能不断增强所推动的。如图 4.2所示，现在个人可以通过固定电话的声耦合器调制解调器访问图形用户界面、鼠标和外部通信。我从未见过有人估计商务旅客在酒店房间使用声耦合器连接互联网所浪费的总时间，但根据我的经验，这个数字相当可观。

This shift was driven by the Internet, GUIs, and the expanding use and power of personal computers. As shown in Figure 4.2, individuals now had access to GUIs, mice, and external communications via acoustic coupler modems for their landline phones. I’ve never seen an estimate for the total amount of time lost by business travelers trying to hook up to the Internet using acoustic couplers from their hotel rooms, but based on my experience, it would be a substantial number.

对于 IT 系统的内部客户来说，许多界面设计都很糟糕，部分原因是技术限制。在 20 世纪 80 年代后期，当终端还是基于字符的时，用户屏幕可能塞满了数据字段——用户友好性很少成为设计目标。如果您是订单处理员，输入速度至关重要，因为您需要每天输入数百个订单。但是，外部用户需要“友好”的界面，因为他们不处理很多订单。在图形界面的早期，设计师混淆了这两个用户组，有时为内部用户提供友好的界面，却大大减慢了他们的速度！良好设计的激励措施和指导方针仍处于起步阶段。这种情况很快就发生了变化。公司现在正在争夺客户点击量，界面设计很快成为成功的关键。Apple、Amazon 和 Microsoft 的 GUI 开发人员投资于界面设计，并将其视为专业角色，而大多数 IT 组织却迟迟没有意识到这一需求。在 20 世纪 80 年代，只有字符终端可用，交易处理系统功能有限，糟糕的用户界面是常态。在那个时代，糟糕的设计不是什么大问题，因为内部员工必须忍受这些设计。但在 20 世纪 90 年代，由于外部客户要求更好的界面，否则他们就会去其他地方，所以情况发生了逆转。

For internal clients of IT systems, many interface designs were awful, in part because of technical constraints. During the late 1980s, when terminals were character-based, user screens might be crammed with data fields—user friendliness was seldom a design goal. If you were an order-processing clerk, speed of entry was paramount, as you were called upon to input hundreds of orders a day. However, external users needed “friendly” interfaces because they didn’t process many orders. In the early days of graphical interfaces, designers mixed up these two user groups, sometimes providing internal users with friendly interfaces that drastically slowed them down! Incentives, and guidelines, for good design were still in their infancy. That soon changed. Companies were now competing for customer clicks, and interface design quickly became critical for success. GUI developers at Apple, Amazon, and Microsoft invested in interface design and identified it as a specialty role, while most IT organizations were slow in realizing the need. In the 1980s, with only character-based terminals available and transaction processing systems limited in capability, truly awful user interfaces were the norm. Poor design was less of a problem during this era because of the simple fact that internal staff had to live with these designs. But in the 1990s, that situation was turned upside down since external customers demanded better interfaces or they went elsewhere.

新的“互联网”公司回避了纪念碑式方法——它们太慢了，不利于创新，而且没有乐趣。起初，这些差异出现在互联网公司和传统公司之间。后来，它们会在公司内部造成隔阂，因为开发互联网系统的团队与传统系统开发团队分道扬镳。传统团队看不起互联网应用程序开发人员，认为他们开发的是“玩具系统”，而互联网团队则对传统开发人员嗤之以鼻，认为他们已经是恐龙了。

The new “Internet” companies eschewed Monumental Methods—they were far too slow, not conducive to innovation, and not fun. At first, these differences showed up between the Internet and traditional companies. Later, they would drive a wedge within companies, as groups developing Internet systems split from legacy system development groups. The traditional groups looked down on the Internet application developers for building “toy systems,” while the Internet groups looked askance at traditional developers as dinosaurs.

对于这些新应用，需求很模糊。过去，当订单处理实现自动化时，分析师会去订单处理部门询问人们的工作情况。虽然任务可能很复杂，但有一个明确的起点。但现在技术很新，需求不断变化，客户用户界面还处于起步阶段。瀑布式生命周期无法处理这种程度的不确定性。

With these new applications, requirements were murky. When order processing was automated in the past, an analyst would go to the order processing department and ask people how they did their work. While tasks might be complicated, there was a definite starting point. But now the technology was new, the requirements changing, and customer user-interfaces in their infancy. Waterfall life cycles were not equipped to handle this level of uncertainty.

互联网的兴起和随之而来的创新帮助颠覆了规范方法的驱动力。许多早期的敏捷主义者——肯特·贝克、阿利斯泰尔·科克伯恩、马丁·福勒、罗恩·杰弗里斯、鲍勃·马丁——在 20 世纪 90 年代中期都是 OOP 大师。在一封电子邮件中，马丁·福勒指出：“从我的第一份工作开始，我就被教导要对瀑布式设计持怀疑态度，所以我已经为敏捷做好了准备。我也是从面向对象 (OO) 的世界开始的，这个世界一直对进化设计有着强烈的偏见，并且有理论工具和软件环境 (Smalltalk) 来实现它。而你，比我们所有 OO 人都更接近主流思想。”

The rise of the Internet and accompanying innovations helped upend the drive to prescriptive methods. Many of the early agilists—Kent Beck, Alistair Cockburn, Martin Fowler, Ron Jeffries, Bob Martin—were OOP gurus during the mid-1990s. In an email exchange, Martin Fowler pointed out, “I was taught to be very skeptical of waterfall from my first job, so I was already primed for agile. I also started in the object-oriented (OO) world, which always had a strong bias towards evolutionary design and had the theoretical tools and software environment (Smalltalk) to pull it off. You, on the other hand, were much closer to mainstream thinking than all of us OOers.”

从结构化方法过渡到 RADical 带来了挑战。正如公司必须学会如何拆解现有产品以推出新产品一样，我也学会了把握时机。我从拥有足够的结构化工作到为 RADical 工作而苦苦挣扎。我在会议演讲中吸引了众多听众，但购买我服务的人并不多。对于那些让我在他们的项目上进行实验的人，我永远心存感激。

Making the transition from structured methods to RADical came with challenges. Just as companies had to learn about cannibalizing existing products to launch new ones, I learned about timing. I went from having sufficient structured work to scratching for RADical work. I drew crowds at conference talks, but not many who bought my services. To the ones who let me experiment on their projects, I am eternally grateful.

耐克

Nike

我从结构化到激进化转型过程中的另一个重大突破是与俄勒冈州比弗顿的耐克公司合作。耐克公司是一个充满活力的地方，到处都是运动员，大楼以迈克尔·乔丹等主要运动员的名字命名，会议室以不太知名的运动员的名字命名。而不是邀请在大楼里开会C，13-002 房间，您已收到前往迈克尔乔丹大楼皮特马拉维奇房间的邀请。

Another big break in my structured to RADical transition was working with Nike in Beaverton, Oregon. Nike was a hopping place, athletes everywhere, buildings named for major athletes like Michael Jordan, meeting rooms named for less well-known ones. Rather than an invitation to meet in Building C, Room 13-002, you got an invite to Building Michael Jordan, Room Pete Maravich.

我在 Nike 工作了几年，主要负责三个方面：实施其第一个 RADical 项目、教授 RADical 开发和促进研讨会以及管理大型企业数据项目。这项工作增强了我对 RADical 实践的信心。

My work at Nike lasted several years and focused on three areas: implementing its first RADical project, teaching workshops on RADical development and facilitation, and managing a large enterprise data project. This work increased my confidence in RADical practices.

介绍我接触登山运动的朋友杰瑞·戈登 (Jerry Gordon) 曾在耐克工作，他让我向一位高管推销 RADical。一个部门的项目进展不顺：仅制作一份需求文档就花了 18 个月，而那时它已经过时了。部门副总裁对缺乏进展感到沮丧。考虑到耐克的非正式性，我在面试高管时最大的担忧是穿什么。休闲商务装和红色耐克跑鞋证明是最佳选择——高管注意到了鞋子，我得到了这份工作。

My friend Jerry Gordon, who had introduced me to mountaineering, had gone to work for Nike, and he brought me in to pitch RADical to a senior executive. A project in one division had run off the rails: It had taken 18 months just to produce a requirements document, and by then it was outdated. The division vice president was frustrated at the lack of progress. My biggest concern approaching this executive interview was what to wear, given the informality at Nike. Casual business dress and red Nike running shoes proved to be just the ticket—the executive noticed the shoes, and I got the job.

使用 Sam 和我开发的方法，我们以一个月为一个周期，在六个月内交付了一款可用的应用程序。IT 员工采用的其中一种技术是使用团队会议（包括 IT 和客户员工）来快速确定业务需求和软件功能。这些小组会议也用于回顾。我最终在多个研讨会上教授这些联合应用程序开发 (JAD) 技术，并帮助 Nike 组建了一支培训师团队。

Using the methodology Sam and I had developed, we used one-month iterations to deliver a working application in six months. One of the techniques that caught on with the IT staff was the use of team sessions, including both IT and client staff, to rapidly identify business needs and software features. These group sessions were also used for retrospectives. I ended up teaching multiple workshops on these Joint Application Development (JAD) techniques and helped Nike build a staff of facilitators.

Nike 项目中的一次争吵凸显了迭代开发在不同功能孤岛中不断遇到的困难。第一次迭代结束后，我与负责该项目的数据库管理员（他参加了我为期三天的 RADical 研讨会）坐下来，列出了第二次迭代所需的数据库更改。

One kerfuffle on the Nike project highlighted a difficulty iterative development would constantly have with different functional silos. After the first iteration, I sat down with the database administrator assigned to the project, who had attended my three-day RADical workshop, and laid out the database changes needed for the second iteration.

“哦，不，”他说，“你不明白。在数据库领域，我们要求数据库设计和实现一次。我们需要定义所有实体和属性；然后我们实现一次。”

“Oh no,” he said, “You don’t understand. In database land, we require the database be designed and implemented once. We need all the entities and attributes defined; then we implement it once.”

我回答道：“你不记得研讨会上说过应用程序是经过不断迭代而出现的，这意味着数据库设计也在不断发展吗？”

I replied, “Don’t you remember from the workshop that the application emerges iteration by iteration, which means the database design evolves also?”

“但是，”他反驳道，“我们部门不是那样工作的。我认为迭代设计只是针对开发人员的。我们不能按照你的方式去做。”

“But,” he countered, “we don’t work that way in my department. I thought the iterative design was just for the developers. We can’t do it your way.”

“很好，”我回答道，“由于之前没有取得任何成果，产品线副总裁批准了这个 RAD 风格的项目。我们一起去她的办公室吧，你可以向她解释一下你的标准工作方式。”

“Fine,” I responded. “The vice president of the product line approved this RAD-style project because of the previous failure to deliver any results. Let’s you and I go up to her office and you can explain your standard way of working to her.”

短暂的停顿之后，他说：“也许我能找到一种方法来实现这个项目。”然后他就这么做了。

After a brief pause, he said, “Maybe I can figure out a way we could do it, just for this project.” And he did.

客户副总裁参加了第一次迭代结束时的客户焦点小组功能演示。在观看了功能演示后，她站起来，感谢了小组成员，并总结道：“这太棒了。我再也不会对 IT 说任何负面的话了！”IT 团队简直不敢相信自己的耳朵。

The customer focus group feature demonstration at the end of the first iteration was attended by the client vice president. After watching the working feature demonstration, she stood, thanked the group, and concluded with the comment, “This is great. I’ll never say anything negative about IT again!” The IT team couldn’t believe their ears.

关于生命周期的哪些部分可以迭代、哪些部分不可以迭代的争论在 Roots 时代后期和 Agile 时代初期反复出现。串行瀑布方法不仅影响了组织设计，还扩展到了更广泛的 IT 行业。与企业孤岛类似，也存在行业孤岛。软件工程研究所 (SEI) 会议由纪念碑方法论者参加，软件会议（如软件开发会议）由传统开发人员参加，面向对象编程会议由面向对象程序员参加，数据库管理会议由数据库设计师参加。每种类型的会议都有自己的追随者参加。最大的分歧发生在数据库和软件开发小组之间，同事 Scott Ambler 和 Ken Collier 可以证明这一点，因为他们多年来一直试图让数据库人群接受敏捷方法。

Arguments about which parts of the life cycle could be iterative and which could not would arise repeatedly during the late Roots and early Agile eras. Not only had the serial waterfall approach impacted organizational design, but it also extended to the wider IT industry. Similar to enterprise silos, there were industry ones. Software Engineering Institute (SEI) conferences were attended by Monumental Methodologists, software conferences like the Software Development conferences were attended by traditional developers, object-oriented programming conferences by object-oriented programmers, and database management conferences by database designers. Each type of conference was attended by its own adherents. The biggest rift was between database and software development groups, as colleagues Scott Ambler and Ken Collier can attest, because they tried for years to get the database crowd to embrace agile methods.

我花了六个月的时间（每周从盐湖城出发）管理耐克的一个项目（我是该项目中唯一的非耐克员工）。在这个项目中，我采用了协作和自组织团队实践。这个企业架构项目涉及众多业务部门，我们需要决定如何处理它们。团队想出了一个主意，专注于讲述当前系统带来的严重负面影响。我对这种方法并不满意，认为这是在浪费时间，但团队很喜欢，所以我们继续进行。我错了。事实证明，这种分析对于向业务经理解释问题的严重程度至关重要，并促成了一项协议，继续执行我们的建议。

I spent six months (traveling from Salt Lake City weekly) managing a project for Nike (I was the only non-Nike person on the project). On this project I employed collaboration and self-organizing team practices. This enterprise architecture project touched a wide number of business departments, and we needed to decide how to approach them. The team came up with an idea to concentrate on stories about the serious negative consequences of the current systems. I wasn’t thrilled with the approach, thinking it was a waste of time, but the team liked it, so we proceeded. I was wrong. This analysis proved to be pivotal in explaining to the business managers the extent of the problem and led to an agreement to move forward with our recommendations.

我还目睹了人们对流动、适应性规划（而不是传统的规定性任务规划）的各种反应。一位团队领导，一位重要的贡献者，在一次员工会议上对一个在他看来模糊的计划感到不安。然后我为他记下了一系列任务，并与团队进行了讨论。会议结束后，另一位团队领导说：“我不认为我们的工作方式是那样的。”“同意，”我回答，“但我需要暂时为他提供一些具体的东西来平息他的沮丧。”

I also witnessed various reactions to fluid, adaptive planning as opposed to traditional prescriptive task plans. One of the team leads, an important contributor, became uneasy in a staff meeting with what seemed to him a fuzzy plan. I then jotted down a series of tasks for him and discussed them with the group. After the meeting, one of the other team leads remarked, “I didn’t think that was how we worked.” “Agreed,” I responded, “but I needed to tamp down his frustration by temporarily providing something concrete for him.”

另一个学习事件涉及决策。几名团队成员需要出差进行焦点小组会议。我仔细考虑了需要做什么，并指派三个人负责这项任务——其中包括一次令人垂涎的前往欧洲办事处的旅行。我认为这只是一个小决定，但团队不同意。他们告诉我，他们并不反对选择谁，但认为应该由团队而不是我来做决定。在建立自组织团队时，谁做出什么决定可以促进自组织或阻碍自组织。回想起这件事，我意识到谁做决定很重要，但同样重要的是团队是否愿意提出这个问题。

Another learning incident involved decision making. Several team members needed to travel to conduct focus group sessions. I thought through what was needed and assigned three individuals to the task—which included a coveted travel stint to offices in Europe. I thought it was a minor decision, but the team didn’t agree. They informed me they didn’t disagree with who was selected, but thought the team should have made the decision, not me. In building self-organizing teams, who makes what decisions can either foster self-organization or hinder it. Reflecting back on this incident, I realized that who made decisions was important, but equally so was that the team felt comfortable raising the question.

研究项目管理书籍和 PMBoK（项目管理知识体系）时，我发现很少提及决策实践。虽然ASD多次提到决策，但更全面的讨论将等待我的《敏捷项目管理》一书（Highsmith，2009 年）。

Researching project management books and the PMBoK (Project Management Body of Knowledge), I found scarce mention of decision-making practices. While ASD contained multiple mentions of decision making, a fuller discussion would await my Agile Project Management book (Highsmith, 2009).

顾问营和杰瑞·温伯格

Consultants’ Camp and Jerry Weinberg

20 世纪 90 年代中期，我应 Lynne Nix 的邀请参加了 Consultants' Camp，这是一项年度静修式活动，在科罗拉多州山城克雷斯特德比特（也是科罗拉多州的野花之都）的 Nordic Lodge 举行。Jerry Weinberg 是这次活动的组织者（其他人也参与了策划），他每年夏天都会召集一群不同的人讨论重要话题并进行长途登山。这是我第一次参加“自己动手”会议。这次会议和其他类似的会议都是使用“开放空间”概念的早期例子。

In the mid-1990s, I was invited by Lynne Nix to join Consultants’ Camp, an annual, retreat-style event held at the Nordic Lodge in the mountain town of Crested Butte, Colorado (also the wildflower capital of Colorado). Jerry Weinberg was the organizer (others participated in the planning) of this event, bringing together a diverse group each summer to discuss weighty subjects and take long mountain hikes. This was my first exposure to a “roll your own” conference. This and other similar meetings were early examples of using “open space” concepts.

第一天早上，小组聚在一起，大家提出可以举办的课程，小组选择并安排课程，然后大家报名。杰瑞总是能提出一些想法。这是我对自我组织的入门。杰瑞会引导和推动，采用与我的适应性研究相一致的领导风格。经常参加夏令营的史蒂夫·史密斯 (Steve Smith) 在 2022 年的对话中谈到了如此新奇的事情：

The first morning, the group gathered, people suggested sessions they could give, the group selected and scheduled sessions, and then people signed up. Jerry always had a few ideas to throw into the mix. It was my introduction to self-organization. Jerry would guide, and nudge, using a leadership style aligned with that emerging from my adaptive research. Reflecting on something so new, frequent camp participant Steve Smith commented in our 2022 conversation:

我知道我完全不明白我们在做什么。自我组织部分对我来说真的很陌生。然后是会议，我不知道会发生什么。我不知道从会议中能提供什么。杰瑞是一个大师级影响者。他只是有点左右事物，他没有强迫任何事情。哦，偶尔他会强迫做出决定，但也许这是必要的。很难说。

I knew I didn’t understand at all what we were doing. The self-organization part was really strange to me. And then the sessions, I didn’t know what to expect. I didn’t know what to offer from a session. Jerry was a master influencer. He just kinda shaped stuff, he didn’t force anything. Oh, occasionally he forced a decision, but maybe it was necessary. It’s hard to say.

很多参加夏令营的人都是杰瑞和丹尼·温伯格创办的问题解决领导力 (PSL) 研讨会的毕业生或讲师。参与者对 PSL 赞不绝口，认为它是一种出色且创新的社交学习体验。“他们真的震撼了你的世界，”史蒂夫说。不知何故，我从未参加过 PSL，尽管它在我的待办事项清单上停留了很长时间。

Many of the camp participants were graduates or instructors of the Problem Solving Leadership (PSL) workshop created by Jerry and Dani Weinberg. Participants raved about PSL as an outstanding and innovative social learning experience. “They really rocked your freaking world,” said Steve. Somehow I never made it to PSL, although it spent a long time on my to-do list.

身材高大的史蒂夫·史密斯和我享受着艰苦的徒步旅行，并谈论当天的话题，尽管呼吸比说话更重要。史蒂夫和我保持着联系，他对我的第一本书做出了重要贡献。我也是在营地第一次见到大卫·罗宾逊；20 年后，他与我合著了《EDGE》（Highsmith、Luu 和 Robinson，2020 年）。然后是 III（发音为 Three）。

Long, tall Steve Smith and I enjoyed strenuous hikes laced with conversations about the day’s topics, although breathing took priority over talking. Steve and I kept in touch, and he made vital contributions to my first book. I also first met David Robinson at camp; 20 years later, he co-authored EDGE (Highsmith, Luu, and Robinson, 2020) with me. And then there was III (pronounced Three).

III（他的法定姓名）每年夏天都会乘坐他那辆 20 世纪 70 年代的迷幻大众巴士来到顾问营，这辆巴士在伍德斯托克或火人节上不会引起轰动。即使在一群不墨守成规的人中，III 也是一个叛逆的、反传统的人。我们推测，他留着长发，不愿意拍照，这要么是他的精神性，要么是他的怪癖。但 III 也很合群，很爱笑，和他在一起很有趣。有趣的是，他喜欢冒险的生活方式让位于传统的工作方式。由于有结构化时代的背景，他倾向于关注人及其互动——特别是引导。他主持项目小组会议并教授引导研讨会。他喜欢冒险的生活方式和谨慎的工作风格相得益彰。他的课程充满了有趣、内容丰富的练习，他的举止鼓励参与者以他们原本不会的方式做出贡献。想象一下，在一个充满乐趣、锻炼的课堂上，你会如何表现自己，而这个课堂是由一个谦逊的、嬉皮士般的 III 老师讲授的，而不是由一个穿着纽扣衬衫和西装、喋喋不休地讲授充满要点的幻灯片的老师讲授。

III (his legal name) would roll into Consultants’ Camp each summer in his psychedelic 1970s Volkswagen bus that would not have caused a stir at Woodstock or the Burning Man festival. Even in a group of nonconformists, III was a rebellious, iconoclast. He had long hair and shunned having his picture taken, part of either his spirituality or his quirkiness, we presumed. But III was also gregarious, quick to laugh, and fun to be around. Interestingly enough, his adventurous lifestyle gave way to traditional ways of working. With a Structured-era background, he had gravitated to focus on people and their interactions—specifically facilitation. He facilitated project group sessions and taught facilitation workshops. His adventurous lifestyle and cautious workstyle played well together. His classes were full of fun, informative exercises, and his demeanor encouraged participants to contribute in ways they would not have otherwise. Think of how you might open up in a fun, exercise-filled class run by an unassuming, hippie-like III versus an instructor in a button-down shirt and suit droning on about slides filled with bullet points.

III 坚持他的项目启动流程，他称之为“特许”——他找到了行之有效的方法并坚持下去。在与 III 合作进行一次客户项目时，我记得曾努力改变一些事情。III 没有让步。我不记得谁最终赢得了争论，但我敢打赌是 III。在随后的几年里，让 III 参与几个客户项目需要仔细选择，因为有些客户会遇到麻烦克服他的外在形象。他们的损失。一旦开始工作，客户就会对他的风格做出积极的反应。

III was adamant about his project kickoff process, which he called chartering—he found what worked and stuck with it. While collaborating with III in one client engagement, I remember trying hard to change a couple of things. III didn’t budge. I don’t remember who finally won the argument, but I bet it was III. Bringing III into several client engagements in subsequent years required careful selection, as some clients would have trouble getting past his external persona. Their loss. Once at work, clients responded positively to his style.

夏令营中充满了激烈的争论。史蒂夫让我想起一个经典的争论，那就是“你能衡量爱吗？”这个问题。许多工程师认为任何东西都可以衡量。进化发展的发明者汤姆·吉尔布和测试专家詹姆斯·巴赫就此展开了争论。汤姆坚持认为“爱”可以通过皮肤电反应来衡量。詹姆​​斯的父亲是畅销书《海鸥乔纳森》（巴赫，1970 年），^{6 岁}的詹姆斯对此不以为然。汤姆自负，詹姆斯讨厌失败。争论持续了整个下午，旁观者进出房间，有时会发表一两条评论。这是一个典型的夏令营讨论问题，两个聪明、固执己见的反传统主义者对峙，他们都不喜欢失败。见解令人愉快，娱乐性十足！

Intense arguments abounded at camp. One classic Steve reminded me of was over the question, “Can you measure love?” Many engineers believed anything could be measured. Tom Gilb, inventor of evolutionary development, and James Bach, a testing expert, squared off. Tom insisted “love” could be measured by galvanic skin responses. James, whose father wrote the iconic best-seller Jonathan Livingston Seagull (Bach, 1970),⁶ was having none of it. Tom had an ego. James hated to lose. The argument ebbed and flowed for most of the afternoon, with onlookers wandering in and out of the room, sometimes chipping in a comment or two. It was a typical camp discussion question, with two smart, opinionated iconoclasts facing off, neither of whom liked to lose. Delightful insights and great entertainment!

6. 《海鸥乔纳森》是一本非常畅销的书，在《纽约时报》畅销书排行榜上连续两年占据榜首。它颂扬了个人的力量和找到自己道路的喜悦。难怪詹姆斯·巴赫对爱情持非衡量性的观点。

6. Jonathan Livingston Seagull was a phenomenal bestseller, spending two years around the top spot on the New York Times best-seller list. It celebrated the strength of the individual and the joy of finding one’s way. No wonder James Bach took a non-measurement view of love.

“文艺复兴人”是对杰里·温伯格的恰当描述。他写过关于软件开发和一般系统理论的文章，​​但他的强项是理解人和变化。他的同事，他的想法和友谊促进了我的职业生涯。同为顾问的詹姆斯·巴赫在杰里于 2018 年去世后写了一篇感人的文章：“杰里向我展示了如何真实而不残忍；如何在充满谎言的世界中保持正直；如何在充满不确定性的情况下自信地生活；如何在向老师学习的同时与老师辩论；如何从学生转变为同事；如何在不征求任何人同意的情况下实现自己的自主权。” ⁷

“RENAISSANCE MAN” would be an appropriate description of Jerry Weinberg. He wrote about software development and general systems theory, but his forte was understanding people and change. He was a colleague whose ideas and friendship enhanced my career. James Bach, a fellow consultant camper, wrote a moving tribute after Jerry died in 2018: “What Jerry showed me is how to be authentic without being cruel; how to have integrity in a world of mendacity; how to live confidently with uncertainty; how to debate your teacher while learning from him; how to transition from student to colleague; how to achieve your own agency without seeking anyone’s consent to do so.”⁷

7.詹姆斯·巴赫对杰瑞的悼念可以在他的网站www.satisfice.com上找到。

7. James Bach’s tribute to Jerry can be found on his website, www.satisfice.com.

史蒂夫·史密斯评论道：

Steve Smith commented:

我从杰里那里学到的一件事是让一个人观察练习，然后向小组报告他们在练习中看到的情况。很简单，对吧？了解练习期间发生的事情至关重要。但大多数人想要给出的是他们的解释。即使我给出了非常具体的指示，人们也会进入解释模式。我想说你的工作是记录你听到的和看到的，你的工作不是解释它。你就像一个法庭记者。我的意思是，这必须是一个标准模式，因为多年来，一遍又一遍，确实发生了这种情况。即使有明确的指示，他们仍然会进入解释模式。

One thing I learned from Jerry was to have someone be the observer of an exercise and then report to the group what they saw during the exercise. Easy, right? Having an outsider’s view of what happened during the session is critical. But what most people want to give are their interpretations. Even when I gave extremely specific instructions, people went to an interpretive mode. And I’d say your job is to record what you hear and what you see, your job is not to interpret it. You’re like a court reporter. I mean, it’s gotta be a standard pattern because over and over again, across years, that happened. Even with explicit instructions, they would still go into interpretive mode.

Jerry 明白，仅仅谈论这样的沟通模式是不够的——它们必须被体验，而他是体验式练习的大师（比如本章前面提到的纸牌屋游戏）。多年后，我参加的一次敏捷主义者会议上就出现了这个确切的解释问题。一位参与者意识到会议“记录员”并没有在活动挂图上记录“数据”，而是在记录他的解释。她要求接手录音工作，专注于记录所说的内容，而不是她对它的解释。

Jerry understood talking about communication patterns like this wasn’t enough—they had to be experienced, and he was the master of experiential exercises (like the House of Cards game mentioned earlier in this chapter). This exact intrepretive problem occurred at an agilists meeting I attended years later. One participant realized the meeting “recorder” wasn’t recording the “data” on the flip chart, but rather recording his interpretation. She asked to take over the recording job and focused on recording what was said rather than her interpretation of it.

杰瑞是一位多产作家，作品涉及各种主题。他的《计算机编程心理学》（Weinberg，1971 年）至今仍保存在我的图书馆中。《心理学》和《一般系统思维导论》（Weinberg，2001 年）都是经典之作。多塞特出版社以“银色版”重新发行了这两本书。

Jerry was a prolific writer on a wide variety of topics. A copy of his Psychology of Computer Programming (Weinberg, 1971) still sits in my library. Both Psychology and his An Introduction to General Systems Thinking (Weinberg, 2001) are classics. Dorset House Publishing reissued both in “Silver Editions.”

Jerry 喜欢格言。这些格言通常以一系列“法则”的形式呈现，简洁地阐述了复杂的思想。以下是几个例子：

Jerry loved aphorisms. Often presented as a series of “laws,” these were pithy statements of complex ideas. Here are a few examples:

• 双胞胎定律：“大多数情况下，无论付出多少努力，都不会产生任何重大事件。”（例如，双胞胎的出生频率是多少？）

• Law of Twins: “Most of the time, no matter how much effort one expends, no event of any great significance will result.” (As in, how often are twins born?)

• 五分钟规则：“客户总是知道如何解决他们的问题，并且总是在前五分钟内告诉解决方案。”

• Five-Minute Rule: “Clients always know how to solve their problems, and always tell the solution in the first five minutes.”

• “如果软件不需要运行，你总是可以满足任何其他要求。”

• “If the software doesn’t have to work, you can always meet any other requirement.”

• “拥有高智商就像拥有超强计算速度的 CPU。这是解决问题的一大优势——只要问题不涉及大量输入或输出。”

• “Having a high IQ is like a CPU’s having a terrific computing speed. It’s a great asset in problem solving—as long as the problem doesn’t involve a lot of input or output.”

杰瑞甚至在《温伯格论写作》（Weinberg，2006）中写到了写作。从那以后，这种方法就成了我写作的基石。有些作者从头开始，从头到尾写。我永远做不到。我按照杰瑞的建议写作：先写出叙事的要点，然后再想办法安排它们。杰瑞审阅了我的第一本书《ASD》，并给了我很好的组织提示，这促使我进行了重大的结构调整，并带来了重大改进。

Jerry even wrote about writing in Weinberg on Writing (Weinberg, 2006). This method has been the cornerstone of my writing ever since. Some authors begin at the beginning and write from front to back. I could never do that. I write like Jerry suggests: First write nuggets of narrative, and then figure out how to arrange them. Jerry reviewed my first book, ASD, and gave me excellent organization hints, which prompted significant restructuring and led to major improvements.

在杰瑞顾问营，我找到了一群志同道合的新朋友，他们为我的进步做出了贡献。在这里，我接触到了自组织团队和萨提尔变革模型，我在与客户打交道时经常使用这种模型。

At Jerry’s Consultants’ Camp, I found a new group of like-minded people who contributed to my evolution. Here I was introduced to self-organizing teams and the Satir model for change that I used frequently in client engagements.

从激进到适应

RADical to adaptive

从激进到适应的转变涉及明确识别和使用思维方式。我最终抓住了激进思维的框架——复杂自适应系统 (CAS) 理论。这一发现促使我将自己的方法从激进转变为适应，并推动了我思维中协作、自组织的团队方面。后来我了解到其他敏捷宣言作者也采用了 CAS 理论。三条线索交织在一起，创造了自适应软件开发 (ASD)：

The transition from RADical to adaptive involved the explicit identification and use of mindset. I finally latched onto a framework for a RADical mindset—complex adaptive systems (CAS) theory. This discovery caused me to relabel my approach from RADical to adaptive and propelled the collaborative, self-organizing team side of my thinking. Later I would learn other Agile Manifesto authors employed CAS theory. Three threads were woven together to create Adaptive Software Development (ASD):

• RADical 软件开发方法

• RADical Software Development methodology

• 合作

• Collaboration

• CAS 思维模式

• CAS mindset

到了 Roots 时代，我们需要超越传统的软件开发方法。我们可以制定计划，然后以最小的偏差执行，我们可以规定算法流程，我们可以预测未来，流程可以消除不良变化，人们是流程机器中的齿轮，但这些想法行不通。严格的流程工程方法试图通过告诫人们更加确定来抵消不确定性——就像告诉珠穆朗玛峰的风暴停止一样有效。

By the Roots era, we needed to move beyond traditional approaches to software development. The mindset that we could develop a plan and then execute it with minimal deviation, that we could prescribe algorithmic processes, that we could predict the future, that processes could drive out ugly variations, that people were cogs in the machinery of process wasn’t working. Strict process engineering methods attempted to counteract uncertainty by admonishing people to be more certain—about as effective as telling a raging Mt. Everest storm to desist.

自 20 世纪 90 年代初以来，一批科学家和管理者就已明确表达了他们对生物体和组织如何进化、如何应对变化以及如何管理其发展的看法发生了深刻转变。科学家对化学反应临界点、鸟类群居和蚂蚁群体行为的发现为组织协作和变革提供了深刻见解。

Since the early 1990s, a vanguard of scientists and managers had articulated a profound shift in their view about how organisms and organizations evolve, respond to change, and manage their growth. Scientists’ findings about the tipping points of chemical reactions, the flocking of birds, and the swarm behavior of ants provided insights into organizational collaboration and change.

合作

Collaboration

瀑布式生命周期导致了功能性组织结构，并强调文档化以弥合它们之间的差距。之前关于 STRADIS 五天课程的故事说明了我对错误的担忧沟通，即使使用图表而不是文字。20 世纪 90 年代中期的另外两次约会让我更加担心。

Waterfall life cycles resulted in functional organizational structures and an emphasis on documentation to bridge the gap between them. The earlier story about a five-day STRADIS class illustrated my concern about faulty communications, even when using diagrams rather than words. Two other engagements during the mid-1990s added to my concerns.

在凤凰城一家教育客户的培训课程中，该项目的系统架构师决定使用 UML 图表来记录他的架构。他说这需要两个月的时间。我说：“好吧，你有两个星期的时间。”之后，他向开发人员做了一个小时的演示。然后他问：“从所有这些图表中，你可以看出如何编码，对吗？”再次，他们茫然地看着我。幸运的是，这位架构师知道如何编码。当他坐下来向开发人员展示如何正确编码架构时，我看到了灵感。顺便说一句，这位架构师抱怨只有两个星期的时间来提出架构。项目进行了四次迭代后，他回复我：“我们不得不重做架构的主要部分。但是，两个月前，无论你给我多少时间，我都不会考虑当前的架构。我终于理解了迭代方法，即使是架构。”

During a training session at an educational client in Phoenix, the systems architect on the project was determined to use UML diagrams to document his architecture. He said it would take two months. I said, “Fine, you have two weeks,” after which he gave a one-hour presentation to the developers. Then came the question, “From all these diagrams you can see how to code it, correct?” Again, blank stares. Luckily this architect knew how to code. As he sat down and showed the developers how to properly code the architecture, I could see the lights going on. As an aside, this architect grumbled about having only two weeks to come up with the architecture. Four iterations into the project, he came back to me: “We had to redo a major part of the architecture. However, two months ago, I would not have considered the current architecture, no matter how much time you had given me. I finally understand an iterative approach, even with architecture.”

东海岸一家金融公司的企业架构团队刚刚提交了他们的架构标准文件。开发团队的回应是：“不理解，忽略了它们。”在与架构师交谈时，我问道：“你们安排了什么样的会议来向开发人员解释你们的工作？”“我们没有时间解释文件中的内容，”他们回答道。“这应该是显而易见的。”显然，事实并非如此。

A corporate architecture group at a financial firm on the East Coast had just delivered their architectural standards document. The development group’s response: “Didn’t understand them, ignored them.” Talking with the architects, I asked, “What kinds of meetings have you scheduled to explain your work to developers?” “We don’t have time to explain what’s in the documents,” they responded. “It should be obvious.” Obviously, it wasn’t.

复杂自适应系统

Complex adaptive systems

我办公室的桌子上放着 EEK，一个完全自给自足、封闭的生态系统。EEK 高 5 英寸，包含藻类、微小的虾和蜗牛以及大量微小的细菌。它们都通过相互交换物质或将光转化为生化能来生存。与此同时，在 EEK 旁边的显示器上，一群数字生物正在交换数字内容。它们生存、相互吞食、交配、生育、进化和死亡——一片用硅创造的人工生命海洋。我用这两种生命观——真实的和人工的——来不断提醒自己要以新的方式思考复杂系统。（Highsmith，1998 年）

On the desk in my office sits EEK, an entirely self-contained, enclosed, living ecosystem. Five inches high, EEK contains algae, miniscule shrimp and snails, and multitudes of microscopic bacteria. They all live by exchanging stuff with each other or converting light to biochemical energy. Meanwhile, on the monitor beside EEK, a forest of digital beings exchange digital stuff. They live, eat each other, mate, give birth, evolve, and die—a sea of artificial life created in silicon. I used these two visions of life, the real and the artificial, as constant reminders of a new way of thinking about complex systems. (Highsmith, 1998)

在我从结构化到敏捷的转变过程中，关键的“顿悟”时刻是发现 CAS 理论。早期的软件开发方法与方法有关。当然，思维模式是存在的，但很少有人费心去表达它们。随着人们开始理解明确的“思维方式”对于软件开发的重要性和影响。

In my transition from structured to agile, the critical “ah ha” moment was discovering CAS theory. Early approaches to software development were about methods. Mindsets were there, of course, but few bothered to articulate them. The Roots era changed that, as people began to understand the importance and implications of an explicit “mindset” for software development.

事实上，这段时间对我影响最大的是科学家，而不是软件开发人员。8我对 CAS 理论的了解源于其中一个记忆黑洞，但可能是布莱恩·亚瑟 1996 年发表的^《哈佛商业评论》文章，紧接着是我最喜欢的书之一，乔治·约翰逊 (1996) 的《心灵之火》。随后是包括生物学家约翰·霍兰德 (1995)、诺贝尔物理学奖获得者默里·盖尔曼 (1995)、米切尔·沃尔德罗普 (1993) 和玛格丽特·惠特利 (1992) 在内的作家的作品。

Indeed, my influencers during this period were more scientists than software developers.⁸ My introduction to CAS theory lies in one of those memory black holes, but it was probably Brian Arthur’s 1996 Harvard Business Review article, quickly followed by one of my all-time favorite books, George Johnson’s (1996) Fire in the Mind. These were followed by works from authors including biologist John Holland (1995), Nobel Prize physicist Murray Gell-Mann (1995), Mitchell Waldrop (1993), and Margaret Wheatly (1992).

8.为了好玩，我统计了ASD中的书籍参考文献：纯科学，19；管理和领导力，38；技术和软件开发，7。

8. For fun I counted book references in ASD: pure science, 19; management and leadership, 38; technology and software development, 7.

^{我开始意识到沟通和协作问题对于使 ASD 9}成为可行的方法至关重要，因此本书的副标题变成了“管理复杂系统的协作方法”，标题中的第一个词也从“激进”变成了“适应” 。此外，ASD 生命周期变成了“推测-协作-学习”（如图 4.3所示），协作成为了我的ASD书的主要焦点。虽然 CAS 理论提供了理论概念，但顾问营提供了这些概念的实际实施，与客户的合作也是如此。

I began to realize communication and collaboration issues were such a critical piece of making ASD⁹ a viable methodology that the subtitle of the book became A Collaborative Approach to Managing Complex Systems, and the first word in the title changed from RADical to Adaptive. Furthermore, the ASD life cycle emerged as “speculate–collaborate–learn” (as shown in Figure 4.3) and collaboration became a major focus of my ASD book. While CAS theory provided the theoretical concepts, Consultants’ Camp provided practical implementations of those concepts, as did working with clients.

9 . 方法论的缩写惯例为 ASD（非斜体），书籍的缩写惯例为ASD （斜体）。其他书籍也同样如此。

9. The convention for abbreviations will be ASD (not italicized) for the methodology and ASD (italicized) for the book. Similarly for other books.

正如量子物理学改变了我们对可预测性的认识，霍兰德改变了我们对进化的看法，CAS 理论也重塑了我们的思维。在快速变化的时代，我们需要更好的模型来感知和响应我们周围的世界。正如生物学家研究生态系统和单个物种一样，高管和经理们需要更好地了解他们公司所处的全球经济和政治生态系统。

JUST AS QUANTUM physics changed our notions of predictability and Holland changed our perspective on evolution, CAS theory reshaped thinking. In an era of rapid change, we needed better models for sensing and responding to the world around us. Just as biologists study both ecosystems and individual species, executives and managers needed to better understand the global economic and political ecosystems in which their companies competed.

复杂自适应系统，无论是生物系统还是经济系统，都是一组基于信息进行交互的智能体，其行为基于简单规则，随着时间的推移而发展，并且经常产生突发性结果。组织集合可能包括团队成员、客户、供应商、高管和其他相互交互的参与者。智能体的行为由一组内部规则驱动，一组简单的规则可以产生复杂的行为和结果，无论是在蚁群中还是在项目团队中。相比之下，复杂的规则往往会变得官僚主义。

A complex adaptive system, be it biologic or economic, is an ensemble of agents who interact based on information, whose actions are based on simple rules, who evolve over time, and who often produce emergent results. An organizational ensemble might include team members, customers, suppliers, executives, and other participants who interact with each other. The agent’s actions are driven by a set of internal rules, and a simple set of rules can generate complex behaviors and outcomes, whether in ant colonies or in project teams. Complex rules, by comparison, often become bureaucratic.

Dee Hock 创造了“混沌”一词来描述适应性强的组织，即在秩序和混乱之间保持平衡的组织。VISA 前首席执行官 Hock 简明扼要地阐述了这一点：

Dee Hock coined the word chaordic to describe adaptable organizations, those balanced on the edge between order and chaos. Hock, the former CEO of VISA, puts it succinctly:

简单、明确的目的和原则会引发复杂、聪明的行为。复杂的规则和规定会导致简单、愚蠢的行为。（Hock，1999）

Simple, clear purpose and principles give rise to complex, intelligent behavior. Complex rules and regulations give rise to simple, stupid behavior. (Hock, 1999)

深入研究 CAS 理论背后的科学，下一个要问的问题是“它如何应用于软件开发？”引起我共鸣的类比如下：

Dipping into the science underlying CAS theory, the next question to ask, “How does it apply to software development?” The analogies that resonated with me were as follows:

• 适应

• Adaptation

• 混沌边缘

• Edge of chaos

• 适者生存

• Arrival of the fittest

• 简单规则

• Simple rules

• 出现

• Emergence

适应是一个混乱、焦虑、兴奋、热情、冒泡和冗余的过程——有点混乱，但又不完全混乱。适应性组织会倾听周围的世界——他们的客户、供应商、员工和竞争对手——并根据他们所学到的东西做出反应，而不是根据某些流程规则告诉他们的东西做出反应。控制导向的管理者陶醉于结构；协作型管理者陶醉于连通性和现实世界的模糊性。

Adaptation is a messy, anxiety-ridden, exciting, exuberant, bubbling, and redundant process—just this side of chaotic, but not quite there. Adaptive organizations listen to the world around them—their customers, suppliers, employees, and competitors—and respond to what they learn, not to what some process rule told them. Control-oriented managers revel in structure; collaborative managers revel in connectivity and real-world ambiguity.

寻找混沌的边缘，介于随机性和结构性之间，可以最大限度地提高创新和学习。连通性和信息为稳定和混乱的双重深渊之间的徘徊提供了支持。“基本论点是，当任何类型的系统（例如蜂巢、企业、经济体）处于结构过多和结构过少的边缘时，它们会‘自我组织’产生复杂的自适应行为，” Shona Brown 和 Kathleen Eisenhardt 写道（1998 年，第 29 页）。结构过多会减少问题解决和创新；结构过少会造成混乱和低效。“比刚好够少一点”是我实施严谨的指导方针。

Seeking the edge of chaos, lodged between randomness and structure, maximizes innovation and learning. Connectivity and information feed the hovering between the twin abysses of stability and chaos. “The underlying argument is when systems of any kind (e.g., beehives, businesses, economies) are poised on the edge between too much structure and too little structure, they ‘self-organize’ to produce complex adaptive behavior,” write Shona Brown and Kathleen Eisenhardt (1998, p. 29). Too much structure reduces problem solving and innovation; too little creates chaos and ineffectiveness. “A little bit less than just enough” is my guideline for implementing rigor.

生物学家约翰·霍兰德 (John Holland) 著有《隐藏的秩序：适应如何构建复杂性》 (1995)。他的前提是达尔文的适者生存理论不足以解释生命的复杂性。霍兰德将其比作龙卷风席卷垃圾场并组装波音 747 的可能性。他假设另一个概念是工作——即适者生存，其中代理（细胞、动物、人）协作形成下一个最高级别的代理。考虑到通信故障和适者生存的概念，我将重点放在协作上，这是适应性发展的一个关键部分。

John Holland, a biologist, was the author of Hidden Order: How Adaptation Builds Complexity (1995). His premise was that Darwin’s survival-of-the-fittest theory was insufficient to explain the complexity of life. Holland compared it to the chance of a tornado sweeping through a junkyard and assembling a Boeing 747. He postulated another concept was at work—namely, arrival-of-the-fittest, wherein agents (cells, animals, people) collaborate to form the next highest-level agent. Thinking about communications failures and the arrival-of-the-fittest concept led me to focus on collaboration as a key part of adaptive development.

涌现是复杂自适应系统的一种特性，它通过各部分的相互作用（自组织代理行为）创造出整体（系统行为）的一些更大特性。涌现结果无法按照正常的因果关系来预测，但可以通过创建以前产生过类似结果的模式来预测。创造力和创新是运作良好的敏捷团队的涌现结果。

Emergence is a property of complex adaptive systems that creates some greater property of the whole (system behavior) from the interaction of the parts (self-organizing agent behavior). Emergent results cannot be predicted in the normal sense of cause-and-effect relationships, but they can be anticipated by creating patterns that have previously produced similar results. Creativity and innovation are the emergent results of well-functioning agile teams.

自适应软件开发书籍

Adaptive software development book

写书一直是我的愿望清单，现在我有足够的背景和经验来考虑这样的项目。与 Sam、Nike 和其他人一起工作让我获得了实际项目的经验。我努力提高自己的写作技巧，部分原因是参加了新墨西哥州圣达菲举办的两场科学作家研讨会，由《纽约时报》作家乔治·约翰逊讲授。乔治与圣达菲研究所关系密切，研讨会加深了我对 CAS 和写作的理解。发表大量文章增强了我的写作能力，尽管我后来了解到写一堆文章与写一本书完全不同。

Authoring a book had been on my bucket list and I now had enough background and experience to consider such a project. Working with Sam, Nike, and others gave me experience with real projects. I was working on bolstering my writing skills, in part by attending two science writers’ workshops in Santa Fe, New Mexico, taught by George Johnson, a New York Times writer. George had close ties with the Santa Fe Institute, and the workshops furthered my understanding of both CAS and writing. Publishing numerous articles had strengthened my writing capabilities, although I was to learn writing a bunch of articles was way different than writing a book.

我从 20 世纪 90 年代中期开始编写《RADical 软件开发》一书。在编​​写过程中，我总觉得缺少了一些东西，于是就把它标记为“第 3 章”。结果发现，CAS 理论正是我所寻找的。

I started working on the RADical Software Development book in the mid-1990s. As I worked, I kept having this niggling feeling something was missing and labeled it “Chapter 3.” CAS theory turned out to be just what I was looking for.

ASD 方法包括四大支柱：知识、实验、思维方式和类比。软件方法和方法论的知识使我能够尝试新方法并从中学习。知识降低了实验的风险。登山提供了一个物理的、内在的类比，帮助人们理解新方法。CAS 概念为进行适当的思维方式转变提供了一个类比。图 4.3显示了 ASD 的自适应生命周期、它的三个主要组件（推测、协作和学习）以及这些组件中的主要过程。

The ASD methodology consists of four pillars: knowledge, experimentation, mindset, and analogy. Knowledge of software methods and methodologies enabled me to experiment with new methods and learn from them. Knowledge mitigated the risk of experimenting. Mountain climbing provided a physical, visceral analogy that helped people understand the new methods. CAS concepts provided an analogy for making the appropriate mindset change. Figure 4.3 shows the adaptive life cycle from ASD, its three main components (speculate, collaborate, and learn), and the primary processes within those components.

ASD这本书的编写过程并不容易。起初，第 3 章包含了所有背景 CAS 理论。幸运的是，Jerry Weinberg 认为将所有理论放在一章中可能会让读者感到困惑。我同意他的观点，重新组织了理论讨论，并将其分散到整本书中。这是一次重大的重组，但也有许多较小的重组，足以让我绝望地认为永远无法完成或出版这本书。最后，我意识到我必须完成它，无论它是否出版。

The ASD book did not evolve easily. At first, Chapter 3 included all the background CAS theory. Luckily, Jerry Weinberg suggested putting all the theory in one chapter might bog readers down. Agreeing with him, I reorganized and spread the theoretical discussion throughout the book. That was a major reorganization, but there were also many smaller ones, enough I despaired of ever finishing, or getting the book published. Finally, I realized I had to finish it for me, regardless of whether it got published.

我把书稿提交给了纽约的 Dorset House Publishing。Dorset 是一家小型的精品软件工程书籍出版商，曾与几位我敬佩的业内知名人士合作过。Dorset House 总裁 Wendy Eakin 给我开了绿灯——她想出版这本书。1997 年 7 月，我提交了第一份手稿。就在 1999 年圣诞节前夕，联邦快递卡车送来了我（和我的妻子）当年收到的最好的礼物（图 4.4）。

I submitted a draft of the book to Dorset House Publishing in New York. Dorset was a small, boutique publisher of software engineering books several industry notables I admired had worked with. Wendy Eakin, the president of Dorset House, gave me a green light—she wanted to publish it. In July 1997, I submitted the first manuscript. Just before Christmas 1999, the FedEx truck delivered the best gift I (and my wife) received that year (Figure 4.4).

如果可以的话，我会把 Jim Highsmith 的书送给所有参与开发大型系统的人——最终用户、经理、IT 专业人员，尤其是 IT 项目经理！Jim 的信息很简单，但至关重要：大型信息系统不必花费这么长时间，不必花费这么多钱，也不必失败。不幸的是，

If I could, I would give a copy of Jim Highsmith’s book to everyone involved in developing large systems—end users, managers, IT professionals, and most especially IT project managers! Jim’s message is simple but vitally important: Large information systems don’t have to take so long, they don’t have to cost so much, and they don’t have to fail. Unfortunately,

尽管吉姆的信息很简单，但对于大多数大型组织来说，实现它却是一项极其困难的任务。（肯·奥尔，摘自《ASD》前言）

as simple as Jim’s message is, making it happen is an enormously difficult undertaking in most large organizations. (Ken Orr, from the foreword to ASD)

ASD荣获 2000 年 Jolt 产品卓越奖，被评为年度最佳软件工程书籍，这真是令人激动不已。在过去的软件开发会议上，我曾亲眼目睹 Jolt 获奖者领奖；获得类似的认可对我来说是一种极大的肯定。

It was beyond thrilling that ASD won the 2000 Jolt product excellence award for the best software engineering book of the year. At past Software Development conferences, I had watched Jolt winners receive their awards; it was a great affirmation to be similarly recognized.

我一直努力写出既有信息量又读起来有趣的故事。我使用了客户故事、对话、类比、非正式和访谈。ASD使用了复杂系统和攀岩的类比——这两者都需要冒险精神。

I’VE ALWAYS STRIVED to write narratives that were both informative and enjoyable to read. I’ve used client stories, dialogue, analogies, informality, and interviews. ASD used the analogies of complex systems and climbing—both of which require an adventurous spirit.

20 世纪 80 年代，我徒步前往北喀斯喀特山脉进行登山旅行。20 世纪 90 年代，我住在盐湖城，那里的每个峡谷都有攀岩设施峭壁，我选择了攀岩。为什么要爬山？登山者的陈词滥调是“因为它就在那里”。对我来说，原因有以下几点：

In the 1980s, I trekked to the North Cascades for mountaineering trips. In the 1990s, living in Salt Lake City, where every canyon contained climbing crags, I opted for rock climbing. Why climb mountains? The climber’s cliché is “Because it’s there.” For me, it’s a handful of things:

• 令人振奋

• Exhilarating

• 乐趣

• Fun

• 走进自然世界（远离办公桌）

• Being out in the natural world (and away from my desk)

• 高度集中注意力

• Intensely focusing

• 鼓励适应

• Encourages adaptation

为什么用登山来类比软件开发？首先，我喜欢登山和软件开发。但主要有三个原因：技能、风险和心态。登山需要多种技能。在登山过程中，你需要掌握攀岩和冰面技术——放置保护装置、绳索处理、天气预报、路线规划等。你还需要风险评估和缓解技能——知道何时继续前进，知道何时后退，识别攀爬是否在你的技能水平之内，何时不在。你只有通过经验、对山峰、地形、天气和能量水平的感受才能学到这些。无论读多少书或做多少计划都无法替代经验。最后，你需要一种适应性心态。你有一个明确的目标，但路径可能会改变。你有限制——时间和条件。你必须不断在微观层面（你周围的环境）和宏观层面（是否要后退的整体评估）进行调整。以规定性心态攀登大山肯定会受伤，甚至更糟。

Why use mountain climbing as an analogy to developing software? Primarily, I enjoyed both. But there are three key reasons: skills, risk, and mindset. Climbing requires a variety of skills. In climbing you need rock and ice techniques—placing protection devices, rope handling, weather forecasting, route planning, and more. You also need risk assessment and mitigation skills—knowing when to push on, knowing when to back off, recognizing when a climb is within your skill level and when it’s not. You only learn this with experience, getting a feel for the mountain, the terrain, the weather, your energy level. No amount of reading or planning substitutes for experience. Finally, you need an adaptive mindset. You have a clear goal, but the path may change. You have constraints—time and conditions. You must constantly adjust at both a micro level (your immediate surroundings) and macro level (overall assessment of whether to back off). Tackling a big mountain with a prescriptive mindset is a sure path to injury, or worse.

这些技能、风险和心态因素同样适用于软件开发人员和组织文化。我并不是建议你冲出去爬山，但我建议你找一项能激发你的冒险精神的活动。

These same factors of skill, risk, and mindset apply to software developers and to organizational culture. I’m not suggesting you rush out and climb a mountain, but I do recommend you find an activity that tweaks your adventurous spirit.

1999 年，当我的ASD书籍即将出版时，我正在寻找有趣的会议参加，并找到了 Cutter Consortium 的年度峰会。那里的演讲者和主题吸引了我，演讲者名单上包括我钦佩的人——Ed Yourdon、Tom DeMarco、Tim Lister 和 Ken Orr。我撰写了几篇由 Cutter 发表的文章，所以我给 Ed Yourdon 发了电子邮件，解释了为什么我应该在会议上发言。Ed 给我回了邮件，说演讲者名额已满，但让我在其中一个讨论小组中占有一席之地。从此，我的职业生涯又一个转折点开始了。

IN 1999, AS my ASD book was nearing publication, I was looking for interesting conferences to attend and found Cutter Consortium’s annual Summit Conference. There were speakers and topics that appealed to me, and the roster of speakers included individuals I admired—Ed Yourdon, Tom DeMarco, Tim Lister, and Ken Orr. I had authored several articles published by Cutter, so I emailed Ed Yourdon, and explained why I should speak at the conference. Ed emailed me back and said the speaker slots were full but offered me a spot on one of the discussion panels. Thus began another of the inflection points in my career.

会议开始前一天晚上，所有演讲者、组织者和小组成员聚在一起吃晚饭，通常是在 Cutter 首席执行官 Karen Coburn 的家里。在这种非正式的场合，晚餐分散在房子各处，我最终坐在了 Cutter 营销副总裁 Anne Mullaney 旁边。当我们谈论 IT 行业的各个方面时，我提到我有一本书即将出版，我喜欢写作。这是那些罕见的明星连珠之一，似乎是复杂性奇异吸引子概念的事件。Ed Yourdon 一直在为 Cutter 撰写每月的软件开发研究报告，他想继续前进。Anne 问我是否有兴趣撰写这份报告。

The evening prior to the conference start, all the speakers, organizers, and panel members gathered for dinner, usually at Cutter CEO Karen Coburn’s home. In this informal setting, with dinners scattered throughout the house, I ended up sitting beside Anne Mullaney, Cutter’s vice president of marketing. As we talked about aspects of the IT industry, I mentioned I had a book near publication, and I enjoyed writing. It was one of those infrequent star alignments that appear to be incidents of complexity’s strange attractors concept. Ed Yourdon had been writing a monthly software development research report for Cutter and wanted to move on. Anne asked if I might be interested in authoring the report.

我答应了，并最终得到了我的第一份写作工作，每月都有固定的截止期限。这份关于开发某个方面的 16 页报告要求我每月确定一个主题，对其进行研究，起草报告，并与编辑一起完善它，这样 Cutter 才能每月通过蜗牛邮件发送它。报告的标题一开始是“应用程序开发策略”，然后改为“电子商务应用程序开发”。这很有趣，是一次很好的学习经历，同时也让人感到焦虑和畏惧。在两年的时间里（1998-2000 年），我撰写了各种各样的主题，包括外包、管理分布式团队、应用程序服务器和知识管理。我以媒体的身份参加会议，让我有机会接触到那些我本来不会与之互动的人。我继续在 Cutter 工作了 10 年。

I said yes and ended up with my first writing job that had a fixed monthly deadline. This 16-page report on some aspect of development required that I decide on a topic each month, research it, draft the report, and work with the editors to refine it, so Cutter could get it into snail mail each month. The report started out with the title “Application Development Strategies” and then shifted to “e-Business Application Development.” It was fun, a great learning experience, anxiety producing, and daunting all at the same time. In two years (1998–2000), I wrote on topics as varied as outsourcing, managing distributed teams, application servers, and knowledge management. I attended conferences as part of the press, giving me access to people with whom I would not have interacted otherwise. I went on to work with Cutter for 10 years.

额外的敏捷根源¹⁰

Additional agile roots¹⁰

10.关于敏捷方法的更多信息，可以在我的敏捷概述书籍《敏捷软件开发生态系统》中找到（Highsmith，2002）。

10. Additional information on agile methodologies can be found in Agile Software Development Ecosystems, my overview of Agile book (Highsmith, 2002).

到了 20 世纪 90 年代中期，我意识到我并不孤单。我找到了一篇早期的 Scrum 论文《Scrum 开发流程》，由 Ken Schwaber 和 Jeff Sutherland 于 1995 年撰写。而 Jeff 和 Ken 的工作则基于 1986 年发表在《哈佛商业评论》上的一篇文章《新新产品开发游戏》（双“新”是正确的），作者是 Hirotaka Takeuchi 和 Ikujiro Nonaka 。

By the middle of the 1990s, I realized I wasn’t alone. I found an early Scrum paper, “Scrum Development Process,” written by Ken Schwaber and Jeff Sutherland in 1995. In turn, Jeff and Ken’s work was based on a 1986 article, “New New Product Development Game” (the double “new” is correct) by Hirotaka Takeuchi and Ikujiro Nonaka in the Harvard Business Review.

20 世纪 90 年代初，曾有一个“敏捷制造”联盟。我没有深入研究它，只是注意到软件社区并不是第一个使用“敏捷”一词的。

In the early 1990s, there was an “agile manufacturing” consortium. I didn’t delve into it, except to note the software community wasn’t the first to use the word “agile.”

Jeff DeLuca 开发了特性驱动开发 (FDD)，部分原因在于他在 1997 年为一家大型新加坡银行工作期间，参与了一个为期 15 个月、50 人的软件开发项目。Jeff 是澳大利亚人，他一直在使用多年来，Jeff 一直致力于开发一个精简、轻量级的流程框架。Peter Coad 被请来开发该项目的对象模型，他一直主张采用细粒度、面向特性的开发框架，但并没有将其嵌入任何特定的流程模型中。这两个线索（一个来自 Jeff，另一个来自 Peter）在这个项目中汇聚在一起，形成了 FDD。我和 Jeff 谈过几次 FDD 和新加坡项目。

Jeff DeLuca developed feature-driven development (FDD) in part based on his work on a 15-month, 50-person software development project at a large Singapore bank in 1997. Jeff, an Australian, had been using a streamlined, lightweight process framework for many years. Peter Coad, who was brought in to develop the object model for the project, had been advocating a granular, feature-oriented development framework but hadn’t embedded it in any particular process model. These two threads—one from Jeff and the other from Peter—came together on this project to fashion FDD. I talked with Jeff several times about FDD and the Singapore project.

1999 年秋天，我与 Kent Beck 交换了手稿——我的ASD手稿换了他的《极限编程解析》（2000 年）手稿。我们立即意识到了我们的共同点，这促使 Kent 受邀参加俄勒冈州 Rogue River 举行的 XP 会议，这是敏捷宣言会议的前身。这是下一个十年的吉祥开端，既结识了新朋友，也发起了敏捷运动。

In the fall of 1999, I exchanged manuscripts with Kent Beck—my ASD manuscript for his eXtreme Programming Explained (2000) manuscript. We instantly recognized our common ground, which led to Kent’s invitation to attend an XP meeting in Rogue River, Oregon, a precursor to the Agile Manifesto meeting. It was an auspicious beginning to the next decade, which both produced new friends and launched the agile movement.

动态系统开发方法 (DSDM) 是 RAD 实践的形式化，出现于 20 世纪 90 年代初期至中期。DSDM 是另一种“专业” RAD 方法。它起源于英国，在欧洲流行，但在美国采用得并不广泛。事实证明，DSDM 是许多公司可行的方法。

The Dynamic Systems Development Method (DSDM) was a formalization of RAD practices that arose in the early to mid-1990s. DSDM was another “professional” RAD methodology. It originated in England and became popular in Europe, but was less extensively adopted in the United States. DSDM has proven to be a viable methodology for many companies.

随着 DSDM 的发展，DSDM 单词的含义也发生了变化，直到最后 DSDM 联盟决定只使用 DSDM，而不解释这些字母代表什么。一开始，根据我与 Dane Falkner ^{11 的}交流，第一个“D”代表“动态”，反映了适应动态变化的能力，“S”反映了对业务“解决方案”的关注。在撰写《敏捷宣言》时，DSDM 联盟董事会成员 Arie van Bennekum 代表 DSDM。

As DSDM evolved, the meaning of the DSDM words changed, until finally the DSDM Consortium decided to just use DSDM, without explanation of what the letters stood for. In the beginning, according to my exchange with Dane Falkner¹¹ the first “D” was for “dynamic,” reflecting the ability to adapt to on-the-fly changes, and the “S” reflected a focus on business “solutions.” At the time the Agile Manifesto was written, Arie van Bennekum, DSDM Consortium board member, represented DSDM.

11. Dane Falkner 当时担任北美 DSDM 联盟主席（2001 年）以及提供 DSDM 培训和咨询服务的美国公司 Surgeworks 的总裁。

11. Dane Falkner was then the chair of the North American DSDM Consortium (in 2001) and president of Surgeworks, a U.S. company that provided DSDM training and consulting services.

直到后来我才知道 Alistair Cockburn 的 Crystal 方法，但他的思想起源于 Roots 十年，精益开发也是如此。其他个人和团队正在以轻量级（敏捷的早期名称）方式工作，但尚未引起人们的关注。

I wasn’t aware of Alistair Cockburn’s Crystal methods until later, but the genesis of his ideas was in the Roots decade, as were those of Lean development. Other individuals and teams were working in a lightweight (the early designation for agile) fashion, but as yet had drawn little attention.

在 1997 年的软件开发大会（由《软件开发》杂志组织）上，我遇到了新西兰惠灵顿的软件教育公司首席执行官马丁·琼斯。马丁邀请我去他 1997 年秋季的软件大会上发表主题演讲。与他和他的员工共事是一种乐趣，这次拜访开启了我十年来在新西兰和澳大利亚的旅行，与 SoftEd 客户合作并在会议上发表演讲。马丁是“澳大利亚”敏捷方法的早期推动者，至今他仍然是我的同事和朋友。在 1997 年的大会上，我还遇到了马丁·福勒（我必须小心谨慎地对待马丁和马丁，以防他们之间产生矛盾），另一个这是一次偶然的会议，它产生了意想不到的敏捷运动后果。Martin、Martyn、Steve McConnell 和我于 2002 年在 SoftEd 会议上相聚（图 4.5）。

At the Software Development conference (organized by Software Development magazine) in 1997, I met Martyn Jones, CEO of Software Education in Wellington, New Zealand. Martyn invited me to give a keynote address at his software conference in the fall of 1997. He and his staff were a joy to work with, and this visit began a decade of travels to New Zealand and Australia working with SoftEd clients and speaking at conferences. Martyn was an early promoter of agile methods “down under,” and he remains a colleague and friend to this day. At the 1997 conference, I also met Martin Fowler (I have to be careful with Martyn and Martin to keep them straight), another one of those serendipitous meetings that had unforeseen agile movement consequences. Martin, Martyn, Steve McConnell, and I got together at the SoftEd conference in 2002 (Figure 4.5).

时代观察

Era observations

20 世纪 90 年代，软件开发的方法和方法论仍然是确定性和正式的，但 RAD 和迭代开发的部分内容开始逐渐流行，尤其是对于快速扩展的互联网应用程序。串行、瀑布式结构主导着业务和 IT，但令人兴奋的新团队结构正在被尝试。人们作为机器中齿轮的思维模式正在被有机、自组织的团队思维模式所取代。敏捷运动的种子正处于萌芽阶段。

In the 1990s, the methods and methodology of software development continued to be deterministic and formal, but slivers of RAD and iterative development began to creep in, especially for rapidly expanding Internet applications. Serial, waterfall structures dominated business and IT, but exciting new team structures were being experimented with. The mindset of people as cogs in a machine was being replaced by one of organic, self-organizing teams. The seeds of the agile movement were solidly in the sprouting stage.

催生“纪念碑式方法论”的思维模式的一个例子——即把人视为流程机器中的齿轮——发表在《Computerworld》的一篇文章中（Anthes，2001 年；不再在线提供），文章内容是关于德意志银行子公司德意志软件印度公司首席执行官阿舒托什·古普塔 (Ashutosh Gupta)。虽然以下段落发表于 2001 年，但它体现了敏捷文化主义者在 20 世纪 90 年代所抱怨的文化。

An example of the mindset that gave rise to Monumental Methodologies—that is, the view of people as being cogs in the machinery of process—was published in a Computerworld article (Anthes, 2001; no longer available online) about Ashutosh Gupta, CEO of Deutsche Software India, a subsidiary of Deutsche Bank AG. Although the following passage was published in 2001, it exemplifies the culture agilists were complaining about in the 1990s.

“有一种误解认为软件开发是一项创造性工作，严重依赖个人努力，”古普塔在高高的空调办公室里说道，办公室里交通拥堵，远离交通繁忙的圣雄甘地路。“事实并非如此。一旦最初的项目定义和规范阶段过去，它只是一项非常耗费人力的机械工作。”（Anthes，2001 年）

“There is this myth that software development is a creative effort that relies heavily on individual effort,” says Gupta from his air-conditioned office high above the din of traffic-clogged Mahatma Gandhi Road. “It is not. It is just very labor-intensive, mechanical work once the initial project definition and specification stage is past.” (Anthes, 2001)

在“敏捷之根”时代，出现了一个短语，那就是建立“软件工厂”。它代表了敏捷时代寻求改变的传统软件开发方法：确定性、人是机器中的齿轮、等级森严——而不是在二十一世纪早期动态、不确定、快速发展、技术蓬勃发展的岁月中背负的包袱。

One phrase that arose during this Roots of Agile era was building a “software factory.” It epitomized the traditional approach to software development the Agile era sought to change: deterministic, people as cogs in the machine, and hierarchical—not the baggage to carry into the dynamic, uncertain, rapidly moving, technological-boom early years of the twenty-first century.

每当你提出一些全新的想法时，你都需要一个陪衬，一个可以与之对抗的风车。对于早期的敏捷主义者来说，这个陪衬就是瀑布式生命周期和巨型方法，它们在文章和书籍中受到抨击。我记得在一次会议上因为对 CMM 发表负面评论而受到斥责。你可能会从敏捷主义者的言论中得出结论，结构化和巨型方法从未带来任何有用的东西——但你错了。在这个时代，我曾与开发团队合作过，我知道我们创造了巨大的价值。系统可能交付得不够快，或者证明不够有用，或者不像设想的那样易于维护，但实践者无疑为接下来的两个时代奠定了基础。

Whenever you propose something radically new, you need a foil, a windmill to tilt against. For early agilists, that foil was waterfall life cycles and monumental methodologies, which were railed against in articles and books. I remember getting rebuked at a conference for saying negative things about the CMM. You might conclude from agilists’ rhetoric that structured and monumental approaches never delivered anything useful—and you would be wrong. Having worked on and with teams of developers during this era, I know we delivered tremendous value. Systems may not have been delivered fast enough or proved useful enough or as easy to maintain as envisioned, but practitioners certainly built a base for the next two eras.

推销新理念需要吹捧新理念的优点，并指出旧理念的不足之处。结构化方法论者抨击无结构的不足之处。敏捷主义者抨击结构过多。看板支持者抨击敏捷冲刺。

Selling new ideas requires touting the advantages of the new and pointing out the deficiencies of the old. Structured methodologists railed against the deficiencies of no structure. Agilists railed against too much structure. Kanban proponents railed against agile sprints.

敏捷先驱需要一种冒险精神——他们追求新的体验和想法，并愿意从实验中学习。冒险的事业带来了创新，而创新发生在计划出错时，人们开始探索未知领域。Kent Beck 激励了一代程序员，他们探索极限编程的未知领域。他敢于冒险，面对批评，但坚持不懈。Jeff Sutherland 和 Ken Schwaber 敢于颠覆他们自己的 Monumental Methodology 业务，以非规范的、基于经验的方法为名，取了一个听起来很奇怪的名字“Scrum”。12^这些敏捷主义者和其他敏捷主义者对现状不满意，并寻求关注组织内部和外部的客户。敏捷主义者抓住复杂自适应系统的概念（一个科学的异类）作为概念基础，帮助解释他们古怪的软件开发方法，这并不奇怪。

Agile pioneers needed an adventurous spirit—they pursued new experiences and thoughts and were willing to learn from experimentation. Adventurous undertakings led to innovations that occurred when plans went awry, and one ventures into the unknown. Kent Beck energized a generation of programmers venturing into the unknowns of Extreme Programming. He took risks and faced criticism but persisted. Jeff Sutherland and Ken Schwaber dared upend their own Monumental Methodology business to champion a nonprescriptive, empirically based approach with the odd-sounding name “Scrum.”¹² These and other agilists were dissatisfied with the status quo and sought to focus on customers both inside and outside organizational walls. It really isn’t a surprise agilists latched onto the concepts of complex adaptive systems, a scientific outlier, as a conceptual foundation that helped explain their outlandish approach to software development.

12 .除了橄榄球爱好者。

12. Except to rugby aficionados.

回顾过去，20 世纪 90 年代是技术和软件开发的关键时期。随着计算机和网络技术的不断进步，开发人员不得不做出重大反应。开创性著作《精益创业》（2011 年）的作者 Eric Ries 将转型定义为“在愿景不变的情况下改变战略”。转型是一种适应性策略，当事情出错时需要采用这种策略——不只是小错，而是大错。这是一种困难的行为，因为“出错”事件会损害一个人的钱包和自尊。但优秀的企业家和冒险家学会了转型并继续前进，20 世纪 90 年代需要许多转型者。

Looking back, the 1990s were pivotal years, for both technology and software development. As computer and network technology advanced repeatedly, developers had to respond in major ways. Eric Ries, author of the ground-breaking book The Lean Startup (2011), defines a pivot as “a change in strategy without a change in vision.” Pivoting is an adaptive strategy required when things go wrong—not just a little wrong, but big-time wrong. It is a difficult behavior because the “go wrong” events damage one’s pocketbook and ego. But good entrepreneurs and adventurers learn to pivot and move on, and many pivoters were needed in the 1990s.

在结束 Roots 时代之前，我必须再次感谢 Tom DeMarco、Ken Orr、Larry Constantine、Jerry Weinberg 和 Ed Yourdon。您可能认为这些软件工程和结构化方法的先驱和杰出人物会抵制引发敏捷革命的新方法、方法论和思维方式，但他们并没有这样做。他们以多种方式支持和鼓励我。Ken 最初对敏捷开发持怀疑态度，并指出了 RAD 的问题，但我们进行了有价值的反复对话。他为我的ASD书写了一篇精彩的序言。Tom 对敏捷运动做出了积极的回应，并为我第二本书《敏捷软件开发生态系统》撰写了序言。Larry 联系我，约我参加一场演出，从此我开始了 RAD 工作。Ed 和 Larry 接受了我的多篇文章，发表在 Ed 的《美国程序员》杂志和 Larry 在《软件开发》杂志的管理论坛上。Ed 鼓励我参加 Cutter 的年度会议，并于 2001 年 7 月在当时颇具影响力的报纸《计算机世界》上写了一篇关于极限编程的好评（Yourdon，2001）。最后，Jerry 向我介绍了协作、自组织的团队，并帮助开发ASD，对此我非常感激。

I couldn’t leave the Roots era without again acknowledging and thanking Tom DeMarco, Ken Orr, Larry Constantine, Jerry Weinberg, and Ed Yourdon. These software engineering and structured methods pioneers and luminaries, whom you might expect to resist the new methods, methodologies, and mindsets that would bring forth the agile revolution, did not. They supported and encouraged me in a number of ways. Ken was initially skeptical of agile development, noting the problems with RAD, but we engaged in valuable back-and-forth conversations. He wrote a wonderful foreword to my ASD book. Tom responded positively to the agile movement and wrote the foreword to my second book, Agile Software Development Ecosystems. Larry contacted me about a gig that started my RAD work. Ed and Larry accepted multiple articles of mine for Ed’s American Programmer magazine and Larry’s management forum in Software Development magazine. Ed encouraged my participation in Cutter’s annual conferences and wrote a favorable article about Extreme Programming in the then influential newspaper Computerworld in July 2001 (Yourdon, 2001). And lastly, Jerry introduced me to collaborative, self-organizing teams and helped in the development of ASD, for which I am most grateful.

敏捷的种子在 1990 年代初萌芽，在 1990 年代末生根发芽，在 2001 年 2 月《敏捷宣言》发表后开花结果。但是，如果没有萌芽和发芽，就不会开花结果。

The seeds of agility germinated in the early 1990s, sprouted in the late 1990s, and flowered after February 2001 with the writing of the Agile Manifesto. But without the germinating and sprouting, there would not have been any flowering.

新的挑战

New challenges

随着新世纪的开始，变革不断加速。世界被世贸中心和五角大楼的恐怖袭击所震撼，并引发了伊拉克战争和长达二十年的阿富汗驻军。在美国，共和党人乔治·W·布什取代民主党人比尔·克林顿成为总统，而后又被民主党人巴拉克·奥巴马取代。安然丑闻震动了金融界，导致安达信会计师事务所倒闭，并导致《萨班斯-奥克斯利法案》的通过。从奥巴马上任前开始，一直持续到他上任的第一届政府，全球范围内的大衰退。格温·史蒂芬妮和碧昂斯等流行音乐新星冉冉升起。在二十一世纪的第二个十年和第三个十年初，COVID-19 疫情和俄乌战争让个人、组织和国家担心这些事件对经济和社会的影响。

As the new century began, change kept accelerating. The world was shaken by the World Trade Center and Pentagon terrorist attacks, which led to the Iraq War and two decades of troop deployments to Afghanistan. In the United States, Republican George W. Bush replaced Democrat Bill Clinton as president, who was then replaced by Democrat Barack Obama. The Enron scandal shook the financial world, taking down the Arthur Andersen accounting firm, and led to the passage of the Sarbanes-Oxley Act. Beginning before Obama took office and continuing into his first administration was the worldwide Great Recession. Rising pop music stars included Gwen Stefani and Beyonce. Continuing through the second decade of the twenty-first century and the beginning of the third, the COVID-19 pandemic and the Russia–Ukraine war left individuals, organizations, and countries worried about the economic and social impacts of these events.

本世纪的前二十年，Cynefin 框架的可预测性水平将从混乱变为近乎无序。互联网推动的变革将继续高速发展，技术将再次加速发展，疫情将以尚未确定的方式扰乱经济和个人，气候变化的加速将笼罩世界。

The first two decades of the century would move the predictability level from chaotic to near disorder in the Cynefin framework. The transformations driven by the Internet would continue in high gear, technology would ramp up yet again, the pandemic would upset economies and individuals in ways yet undetermined, and the acceleration of climate change would overshadow the world.

2003 年，尼古拉斯·卡尔在《哈佛商业评论》上发表了一篇颇具争议且时机极为不合时宜的文章，题为《IT 并不重要》。卡尔在文中指出，IT 已成为一种商品，因此无法为可持续的竞争优势做出贡献。值得注意的是，这篇文章强调，降低成本是商品产品取得成功的途径。

In 2003, Nicholas Carr wrote a controversial, and hugely mistimed, article in the Harvard Business Review titled “IT Doesn’t Matter.” In it, Carr argued that IT had become a commodity and, therefore, could not contribute to sustainable competitive advantage. Notably, this article emphasized the focus on cost reduction as the path to success for a commodity product.

十年后，哥伦比亚商学院教授丽塔·麦格拉斯（2013）写道，在当今快节奏、不确定的世界中，可持续的竞争优势本身已不复存在，取而代之的是短暂的竞争优势，而快速学习和适应是成功的秘诀。在卡尔的世界里，IT 应该受成本考虑的支配。在麦格拉斯的世界里，响应能力和客户价值应该推动 IT 发展。难怪 IT 高管感到困惑。两位著名的管理学教授对信息技术的未来提出了截然相反的观点。

Ten years later, Rita McGrath (2013), a professor at Columbia Business School, wrote that in today’s fast-paced, uncertain world, sustainable competitive advantage itself was no more, and had been replaced by transient competitive advantage in which learning and adapting quickly were the tickets to success. In Carr’s world, IT should be governed by cost considerations. In McGrath’s world, responsiveness and customer value should drive IT. No wonder IT executives were perplexed. Here were two well-known management professors providing diametrically opposite views on the future of information technology.

在商业世界的混乱中，IT组织面临着五大艰巨的挑战。

AWASH IN THE TURMOIL of the business world, IT organizations faced five daunting challenges.

首先，客户需求激增。互联网带来的机遇和对落后的恐惧加倍了企业快速推出面向客户的创新应用的压力。招聘和留住技术人才变得困难重重。

First, customer demand exploded. The opportunities dangled by the Internet and the fear of getting left behind redoubled the pressure on firms to churn out innovative customer-facing applications quickly. Acquiring and retaining technical talent proved difficult.

其次，随着应用程序从自动化内部业务流程转变为满足外部客户需求，公司必须创新并扩展其技术和产品设计能力。用户界面设计师、产品负责人、数据科学家和体验设计师等新专业需要新的投资。其中一些能力已被互联网软件公司采用，但对于 IT 组织而言，大多数都是新的。

Second, as applications transitioned from automating internal business processes to satisfying external customer needs, companies had to innovate and expand their technical and product design capabilities. New specialties like user interface designer, product owner, data scientist, and experience designer required new investment. Some of these capabilities had already been adopted by Internet software companies, but for IT organizations, most were new.

第三，在 20 世纪 90 年代中后期，为了解决令人担忧的 Y2K（2000 年）“技术债务”问题，组织不得不投入大量资源进行软件维护。由于许多遗留系统使用两位数的日期字段，人们担心当 1999 年 12 月 31 日过渡到 2000 年 1 月 1 日时，会出现混乱。老公司花费数亿美元修复这些遗留系统问题，而较新的互联网公司则没有如此昂贵的负担。

Third, in the mid-to-late 1990s, organizations had to invest substantial resources in software maintenance to thwart the feared Y2K (Year 2000) “technical debt” problem. Because many legacy systems used a two-digit date field, a fear arose that when December 31, 1999, rolled over to January 1, 2000, chaos would ensue. Older companies spent hundreds of millions of dollars fixing these legacy systems problems while newer Internet companies had no such expensive baggage.

第四，技术债务（第 7 章中介绍）一直在快速增长，但对于企业高管来说，除了 Y2K 问题外，几乎是看不见的。IT 人员努力说服企业领导者批准减少技术债务所需的投资，从而实现持续的价值交付。

Fourth, technical debt (covered in Chapter 7), which had been growing rapidly, was still almost invisible to business executives, with the exception of the Y2K problem. IT staff struggled to convince business leaders to approve the investments required to reduce technical debt, thereby enabling continuous value delivery.

第五，IT 组织面临 IT 高成本的压力。20 世纪 90 年代的挑战、“将所有产品运往印度”战略以及 Y2K 投资使许多公司没有资金或人才库来应对 21 世纪的压力。Y2K 不仅成本高昂，而且这些投资也用于拥有旧技能（COBOL、汇编语言、Fortran）的人员，而不是互联网时代所需的新技能。

Fifth, IT organizations faced pressure from the high costs of IT. The challenges of the 1990s, the “ship everything to India” strategy, and their Y2K investments left many companies without the money or the talent pool to respond to the pressures of the 2000s. Not only was Y2K expensive, but those investments were also devoted to people with old skills (COBOL, Assembler, Fortran), not the new skills needed in the Internet era.

尼古拉斯·卡尔 (2003) 描述的以成本为中心的方法也加剧了这些趋势。就在企业试图应对这五大挑战时，《哈佛商业评论》的一篇文章（许多首席执行官都高度尊重该刊物）宣称 IT 并不重要。在这篇文章发表后，有多少 CIO 难以向首席执行官和首席财务官解释他们的投资预算要求？巨型方法论不再能胜任解决这些问题的任务，因此敏捷方法应运而生。

Adding to these trends was the cost-centric approach described by Nicolas Carr (2003). Just as businesses were trying to respond to these five challenges, an article in the Harvard Business Review—a publication highly respected by many CEOs—declared IT didn’t matter. How many CIOs struggled to explain their investment budget requests to their CEOs and CFOs in the aftermath of this article? Monumental Methodologies were no longer up to the task of solving these problems, so agile methods took up the gauntlet.

马丁·福勒

Martin Fowler

2022 年夏天，我与 Martin Fowler 进行了交谈，了解他对敏捷运动的起源的看法。Martin 和我第一次见面是在 1997 年的新西兰，在接下来的二十年里，我们的道路不断交织，包括我们在 Thoughtworks 共事的时光。

In the summer of 2022, I talked with Martin Fowler to get his thoughts on what sparked the agile movement. Martin and I first met in New Zealand in 1997, and our paths continued to intersect over the next two decades, including our time together at Thoughtworks.

您对我们第一次在新西兰见面有什么印象？

What do you remember from our first meeting in New Zealand?

好吧，我去听这位老家伙的演讲，希望听到结构化方法和传统开发。您的演讲让我坐下思考，这个人理解迭代、协作方法，并且了解复杂性理论如何为他的方法论提供概念基础。

Well, I went to this older guy’s talk, expecting to hear about structured methods and traditional development. What you presented caused me to sit up and think, this guy understands an iterative, collaborative approach and has a handle on how complexity theory provides a conceptual basis for his methodology.

您认为敏捷概念为何会流行？

Why do you think agile concepts caught on?

我认为一个重要因素是 Ward 的 wiki。1^这导致了大量关于极限编程 (XP) 细节的分享。XP 讨论占据了 wiki 的大部分，而 Ward 原本打算将 wiki 用作模式讨论。这是讨论 XP 的真正触发点。

I think a big factor was Ward’s wiki.¹ That led to a lot of sharing of the details of Extreme Programming (XP). XP discussions sort of took over the wiki, which Ward had intended to be about patterns. It was a real trigger point talking about XP.

1.Ward Cunningham 发明了 Wiki，与 Kent Beck 和 Ron Jeffries 并列为 XP 的三位早期推动者。

1. Ward Cunningham invented Wiki and was one of the three early promoters of XP, along with Kent Beck and Ron Jeffries.

我在 1997-1998 年间开始为《分布式计算》杂志撰写有关这些概念的文章。文章包括“保持软件的灵活性”和“万能的砰砰声”（关于文档） ^。2

I started writing about these concepts for Distributed Computing magazine in the 1997–1998 time frame. The articles included “Keeping Software Soft” and “The Almighty Thud” (about documentation).²

2.两篇文章均可在 Martin 的网站 ( martinfowler.com ) 上查阅。

2. Both articles are available on Martin’s website (martinfowler.com).

XP 的故事是从克莱斯勒发生的事情发展而来的，这成为了讨论的真正触发点。我自己也写过类似的东西。

The XP story was developing from what happened at Chrysler, and that became a real trigger point for talking. I certainly wrote about stuff along those lines myself.

我做的另一件事可能不那么明显，但可能产生了一些影响，那就是我的《UML 精粹》（Fowler，1999 年；第一版，1997 年）非常受欢迎，因为当时 UML 很流行。我特意写了第 2 章，基本上是为了颠覆重方法论的潮流，并讨论 XP 之类的东西。我不知道我是否提到了 XP 的名字。我肯定是朝着这个方向努力的，因为我想让人们远离巨型方法论。

Another thing I did that may not be so obvious but may have had some impact was my UML Distilled book (Fowler, 1999; first edition, 1997) was extremely popular because UML was a thing at that time. I deliberately wrote Chapter 2 to basically subvert the movement towards heavy methodologies and talk about things like XP. I don’t know if I mentioned XP by name. I certainly pushed in that direction because I wanted to push people away from the Monumental Methodologies.

有趣的是，20 世纪 80 年代的结构化图表被合并到了 Monumental Methodologies 中，而如果我理解正确的话，您试图做的就是使用 UML 来阻止这种情况。

It’s interesting that structured diagrams from the 1980s were combined into Monumental Methodologies, and what you were trying to do, if I understand you, was to head that off with UML.

是的，我向人们介绍了一种思维方式和讨论迭代风格的早期方法论书籍。例如，Kenny Rubin 的书，或者 Grady Booch (1995) 的《对象解决方案》。我还提到 Kent Beck 正在写一本关于项目经理模式的书，这应该是一本很好的资源。

Yeah, I pointed people towards a way of thinking and towards early methodology books that talked about iterative styles. Kenny Rubin’s book, for instance, or Grady Booch’s (1995) Object Solutions. And I mentioned that Kent Beck was working on a book on project manager patterns and that it should be an excellent resource.

当时还写了什么？

What else was being written at that time?

需要记住的一点是，这些书虽然推动了这种更加迭代的风格，但远没有 XP 那样积极。他们的观点是，你希望每隔几个月进行一次迭代；也许六个月的迭代在当时似乎有些激进。而 Kent 则将其定为一个月，甚至两周。我认为 Kent 真正做出贡献的另一件事是，只要你有良好的测试和良好的设计改进方法，设计就可以改进，这就是重构。

One of the things to bear in mind is these books, while pushing towards this more iterative style, weren’t anywhere near as aggressive about it as XP was. The sense from them was you want to iterate every few months; maybe a six-month iteration seemed radical at the time. And then Kent goes to a month, or even two weeks. I think the other thing Kent really contributed was a notion that design can evolve, providing you’ve got good tests and a good way of evolving the design, which was refactoring.

Smalltalk 有什么影响？

What impact did Smalltalk have?

你可以使用 Smalltalk 以相当模块化、结构化的方式快速开发，从而让你不断发展。因为你可以用 Smalltalk 快速构建，所以它开启了一整套当时人们无法获得的可能性。对短迭代的关注大部分来自人们使用 Smalltalk 的经验。

You could develop rapidly with Smalltalk in a decently modular, structured way that allowed you to evolve. Because you could build well with Smalltalk quickly, it opened a whole set of possibilities that were just otherwise unavailable to people at that time. Much of the focus on short iterations came out of people’s experience with Smalltalk.

正如 Martin 的评论所表明的那样，敏捷的种子来自许多地方和许多人。软件开发人员来自不同的视角，他们或多或少地接受敏捷信息。Todd Little 孜孜不倦地推动敏捷开发，本章后面将介绍他对这个问题的看法：

The seeds of agility came from a number of places and people, as Martin’s comments suggest. Software developers came from different perspectives that were more, or less, amenable to the agile message. Todd Little, whose tireless promotion of agile development is described later in this chapter, added his perspective on this issue:

我特别享受敏捷之前的日子，因为我的生活道路与敏捷相似，1979 年在休斯顿埃克森生产研究公司开始职业生涯。虽然有很多相似之处，但开发工程软件与开发业务系统略有不同。我们都是化学和石油工程师，业务和 IT 之间从未存在过鸿沟。我们仍然处于狂野西部时期，但当我回顾我的职业生涯时，我避开了大型方法，尽管我知道它们存在。CMM 很有趣，但它与我的工程背景或我开发软件的方式不一致。我认为我所经历的更像是一条从狂野西部到敏捷的更稳定的进化道路。

I particularly enjoyed the pre-agile days as I lived a similar path, starting my career a bit later in 1979 at Exxon Production Research in Houston. While there were a lot of similarities, working on engineering software was a bit different than working on business systems. We were all chemical and petroleum engineers and never had the chasm between business and IT. We still had our Wild West period, but as I look back over my career, I avoided the mega methodologies even though I knew they were around. CMM was intriguing, but it just didn’t jive with my engineering background or with how I had been developing software. I think what I experienced instead was more of a steadier evolutionary path from the Wild West to agility.

我与 Trimble 的合作进一步指出了使用非传统方法进行软件开发的优点和缺点^。3

My work with Trimble further points out the upside, and the downside, of using nontraditional approaches to software development.³

3.在与 Glen Alleman 的早间咖啡会谈中，他提醒我，在大型、任务关键型航空航天系统方面有着丰富的经验，航空航天系统开发中迭代、增量开发的历史悠久。我没有深入研究这些系统的根源，因为我没有亲身体验过它们。我希望有人能写出这段历史。

3. At a morning coffee session with Glen Alleman, who has significant experience with large, mission-critical aerospace systems, he reminded me there was a rich history of iterative, incremental development within aerospace systems development. I haven’t delved into the roots of these systems since I don’t have personal experience with them. I hope someone else writes about this segment of history.

Trimble 导航⁴

Trimble Navigation⁴

4.这里介绍的 Trimble Navigation 故事是 Highsmith (2002) 的编辑版本。

4. The Trimble Navigation story presented here is an edited version from Highsmith (2002).

2000 年 8 月，我在新西兰旅行期间，为 Trimble Navigation 提供咨询并举办了一场关于自适应开发的研讨会。Trimble 在各种产品中使用全球定位系统 (GPS) 技术，包括用于土地测量和建筑市场的设备。其手持式测量控制器单元运行在专有操作系统上，是多种产品的核心部件。

I consulted and conducted a workshop on adaptive development for Trimble Navigation during one of my trips to New Zealand in August 2000. Trimble uses global positioning system (GPS) technology in a wide variety of products, including equipment for the land survey and construction markets. Its hand-held Survey Controller unit ran on a proprietary operating system and was a core piece of several products.

这次 Trimble 合作是在 2001 年敏捷宣言会议之前进行的。我当时还在测试我的方法，我确信我从 Trimble 员工那里学到的东西和他们从我这里学到的东西一样多。他们已经做的事情再次证实了我所提倡的方法在实践中也发挥了作用。这些课程也让他们确信，他们并不孤单，其他人也在采用类似的方法。

This Trimble engagement took place just prior to the Agile Manifesto meeting in 2001. I was still testing my approach, and I’m sure I learned as much from the Trimble staff as they learned from me. What they were already doing was another confirmation that the methods I was advocating worked in practice. The sessions were also confirmation for them that they were not alone, that others were pursuing similar methods.

我对他们的团队管理方法很感兴趣。“我们不会围绕每个项目组建新团队，”迈克尔说，“我们先组建团队，然后把工作交给他们。”这真是一个好主意——让工作良好的团队保持在一起，而不是不断地重组他们。在这种情况下，“团队”这个词本身就失去了意义。

I was fascinated by their approach to teams. “We don’t organize a new team around each project,” said Michael, “we build up teams and then throw work at them.” What a concept—keeping well-working teams together rather than continuously reorganizing them. The word team itself lost meaning in this setting.

Survey Controller 产品团队没有使用特定方法。“我们从‘编码和修复’开始，听取了大量用户的意见，并根据各种良好工程理念慢慢调整，但对‘什么才是真正有效的’有着严格的要求，”Michael 说。“我们基本上会为当前情况发明一个流程并加以应用。”Trimble 的流程包括功能驱动、时间限制交付，其中主要的客户价值是交付时间表。功能根据需要进行权衡，成本则不那么重要。

The Survey Controller product team didn’t use a particular named methodology approach. “We started with ‘code-and-fix’ with a lot of input from users and slowly adapted according to various ideas of good engineering, but with a severe eye to ‘what actually works,’” said Michael. “We would basically invent a process for the current situation and apply it.” Trimble’s process included feature-driven, time-boxed delivery in which the dominant customer value was delivery schedule. Features were traded off as needed, and costs were of less importance.

Michael 将团队的流程定义为“极其”轻量级。轻量级意味着没有书面设计文档。“我们倾向于有书面要求和规范，但我们目前正在寻求减少书面材料的数量。轻量级意味着接受我们无法识别和控制每一项小任务。轻量级意味着我们不会提交太多状态报告。我们倾向于尝试而不是彻底分析它们。轻量级意味着我们花很少的时间进行估算。”

Michael defined the team’s process as “extremely” lightweight. Lightweight meant no written design documentation. “We tend to have written requirements and specifications, but we are currently looking to reduce the level of written material. Lightweight means accepting we cannot identify and control every little task. Lightweight means we don’t submit much in the way of status reports. We tend to just try things rather than analyze them to death. Lightweight means we spend little time on estimates.”

迈克尔说：“我们发现我们花时间去抵挡其他人关于良好实践的想法。”团队的改进过程是持续的小变化，大部分是简化。

According to Michael, “We find we expend time to fend off other people’s ideas about good practices.” The team’s improvement process was of continuous small changes, mostly simplifications.

这个团队制定了一套原则和价值观来定义他们的软件“文化”。他们用一种令人着迷的过程构建了这些定义并写下来。除了前面提到的“永远不要做浪费时间的事情”原则之外，他们的文化指南还包括：

This team developed a set of principles and values that defined their software “culture.” Using a fascinating process, they constructed these definitions and wrote them down. In addition to the “Never do anything that wastes time” principle cited earlier, their cultural guides included:

• 正统观念几乎总是错误的——即使它是正确的，也必须根据当地情况进行修改。

• The orthodox is almost always wrong—and when it’s right, it must be refitted for local conditions.

• 认真思考代码。除了代码之外什么都没有（也许除了测试用例）。代码最重要的属性是可读性。

• Think hard about the code. There is nothing other than the code (except, maybe, the test cases). The most important attribute of the code is readability.

• 进程必须以人为本，而不是相反。

• The processes must be ordered around the people, not vice versa.

• 持续制定计划，但不要写下来。（实际上，团队确实经常使用白板。）

• Plan continuously but don’t write plans down. (Actually, the teams do use whiteboards a lot.)

• 简单是好的。保持简单需要很高的技巧。

• Simple is good. It takes great skill to keep things simple.

“项目非常成功，因为它们基本按时完成了所需的功能，”Michael 说道。“产品几乎没有任何缺陷，产品负责人对我们非常满意。”

“Projects have been very successful, as they are pretty much on time with the required functionality,” said Michael. “The product is relatively bug free, and the product owner is very pleased with us.”

然而，Michael 的轻量级流程并没有激起其他 Trimble 开发团队的兴趣。Michael 感叹道：“对于其他团队来说，我们太激进了。”其他团队认为 Survey Controller 团队完全缺乏方法，而不是一套专注于基本要素的轻量级方法。这是当时的典型情况，因为轻量级方法被反对者称为“临时的”。

However, Michael’s lightweight process didn’t excite other Trimble development groups. “We are too radical for other groups,” Michael lamented. Other groups viewed the Survey Controller team as having a total lack of methods, rather than a set of lightweight methods focused on the essentials. This was a typical situation at that time as lightweight methods were labeled “ad hoc” by opponents.

敏捷宣言

The Agile Manifesto

敏捷推动未来，当前文献（2018-2022 年）—— 《哈佛商业评论》、《福布斯》、《麻省理工学院斯隆管理评论》和《麦肯锡洞察》 ——大肆宣扬 IT 和企业敏捷性的必要性。但 2001 年的情况并非如此。敏捷热潮始于管理界的一些领导者和敏捷软件先驱者发表的《敏捷宣言》。到 2000 年，敏捷开发的根基已足够强大，可以支持增长。随着我们这些从事这些实践的人了解到其他“轻量级”方法学家和方法论，我们聚集在一起并在各自做的事情上进行协作的能量就加速了。第一次会议由 Kent Beck 在俄勒冈州组织。随后是在犹他州斯诺伯德举行的现已著名的会议，向全世界宣布了这一运动。

Agility drives the future, touts the current literature (2018–2022)—in the Harvard Business Review, Forbes, MIT Sloan Management Review, and McKinsey Insights—with a growing landslide of articles advocating the necessity of IT and enterprise agility. But it wasn’t this way in 2001. The rush to agility started with a trickle, from a few leaders in the management community, and from the agile software pioneers with the publication of the Agile Manifesto. By the year 2000, the roots of agile development were robust enough to support growth. As those of us engaged in these practices learned about other “light” methodologists and methodologies, the energy to get together and collaborate on what we were each doing separately accelerated. The first meeting was organized by Kent Beck in Oregon. It was followed by the now famous meeting at Snowbird, Utah, which announced the movement to the world.

最终，这场敏捷软件运动推动了软件开发的变革。最初的敏捷涓涓细流变成了小溪，然后是河流，最后是无法阻挡的洪水。

Ultimately, this agile software movement propelled the transformation of software development. The initial agile trickle became a stream, then a river, and finally a flood that couldn’t be stopped.

^{2001 年 2 月 11 日至 13 日，在位于犹他州瓦萨奇}山脉小棉白杨峡谷顶部附近的雪鸟度假村旅馆，17 人^5、6聚在一起聊天、滑雪、放松，并试图找到共同点。7^由此诞生了《敏捷宣言》。来自极端组织的代表编程、Scrum、DSDM、自适应软件开发、Crystal、功能驱动开发和实用编程，以及其他赞同需要替代文档驱动的大型软件开发流程的人员聚集在一起。Little Cottonwood Canyon 拥有很棒的休闲攀岩和“香槟”粉雪滑雪。Snowbird Cliff Lodge 本身拥有 115 英尺高的攀岩墙，一些世界上最好的攀岩者曾在这里比赛过。

On February 11–13, 2001, at the Lodge at Snowbird Resort located near the top of Little Cottonwood Canyon in the Wasatch mountains of Utah, 17 people^{5, 6} met to talk, ski, relax, and try to find common ground.⁷ What emerged was the Agile Manifesto. Representatives from Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, feature-driven development, and pragmatic programming, and others sympathetic to the need for an alternative to documentation-driven, monumental software development processes, convened. Little Cottonwood Canyon hosts great recreational rock climbing and “champagne” powder skiing. The Snowbird Cliff Lodge itself has a 115-foot climbing wall on which some of the world’s best climbers have competed.

5. 17 个人，全部是男性。我们因团队缺乏多样性而受到批评，这是理所当然的。

5. Seventeen people, all men. We have been criticized, and rightfully so, for the lack of diversity in the group.

6. Kent Beck、Mike Beedle、Arie van Bennekum、Alistair Cockburn、Ward Cunningham、Martin Fowler、James Grenning、Jim Highsmith、Andrew Hunt、Ron Jeffries、Jon Kern、Brian Marick、Robert C. Martin、Steve Mellor、Ken Schwaber、Jeff Sutherland、Dave Thomas。

6. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas.

7.本节包含我撰写的宣言历史的编辑版本，并发布在敏捷宣言网站上。

7. This section contains an edited version of the manifesto history that I wrote and is posted on the Agile Manifesto website.

Snowbird 会议的召开源于 2000 年春季 Kent Beck 在俄勒冈州 Rogue River Lodge 组织的 XP 支持者和一些“局外人” ^{8 的}早期聚会。在 Rogue River 会议上，与会者表达了对各种“轻量级”方法的支持，但并未正式召开。这次会议是我认识 XP 推动者的机会。2000 年，人们撰写了文章，提到了“轻量级”或“轻量级”流程类别，例如 XP、自适应软件开发、Crystal 和 Scrum。在谈话中，没有人真正喜欢“轻量级”这个绰号，但它似乎暂时被沿用了。

The meeting at Snowbird was incubated at an earlier get-together of XP proponents, and a few “outsiders”⁸ like me, organized by Kent Beck at the Rogue River Lodge in Oregon in the spring of 2000. At the Rogue River meeting, attendees voiced support for a variety of “light” methodologies, but nothing formal occurred. This meeting was my introduction to the movers and shakers of XP. During 2000, articles were written referencing the category of “light” or “lightweight” processes such as XP, Adaptive Software Development, Crystal, and Scrum. In conversations, no one really liked the moniker “light,” but it seemed to stick for the time being.

8.我第一次写这部分时，里面有这样一句话：“其他人，比如阿利斯泰尔和我。”我确信他参加了那次会议——但在 2022 年中期的讨论中，他说那不是他。记忆就是这么有趣。

8. When I first wrote this section, it contained the phrase “others like Alistair and me.” I was sure he was at that meeting—but during our discussion in mid-2022 he said it wasn’t him. Memory is funny that way.

2000 年 9 月，“叔叔”鲍勃·马丁 (Bob Martin) 通过一封电子邮件开启了下一步：“我想在 2001 年 1 月至 2 月期间在芝加哥召开一次小型（两天）会议。这次会议的目的是将所有轻量级方法的领导者聚集在一个房间里。欢迎大家参加；我很想知道我还应该联系谁。”鲍勃建立了一个 Wiki 网站，讨论非常热烈。

In September 2000, “Uncle” Bob Martin initiated the next step with an email: “I’d like to convene a small (two day) conference in the January to February 2001 time frame here in Chicago. The purpose of this conference is to get all the lightweight method leaders in one room. All of you are invited; and I’d be interested to know who else I should approach.” Bob set up a Wiki site and the discussions raged.

早些时候，阿利斯泰尔·科克伯恩（Alistair Cockburn）在一封书信中表达了对“光”一词的普遍不满：

Early on, Alistair Cockburn weighed in with an epistle identifying the general disgruntlement with the word light:

我不介意这种方法论被称为轻量级，但我不确定我是否愿意被称为参加轻量级方法论会议的轻量级人士。这听起来就像一群瘦弱、智力低下、轻量级的人试图记住今天是星期几。我们希望我们作为敏捷联盟共同努力，能够帮助我们这个行业的其他人以新的方式思考软件开发、方法和组织。如果是这样，我们就实现了我们的目标。

I don’t mind the methodology being called light in weight, but I’m not sure I want to be referred to as a lightweight attending a lightweight methodologists meeting. It somehow sounds like a bunch of skinny, feebleminded, lightweight people trying to remember what day it is. We hope our work together as the Agile Alliance helps others in our profession to think about software development, methodologies, and organizations, in new ways. If so, we’ve accomplished our goals.

如此大规模的冒险家和不墨守成规者聚集的会议实属罕见，而 2001 年会议的成果则具有象征意义——敏捷软件开发宣言——所有参与者签署。我们称自己为敏捷联盟。

A bigger gathering of adventurers and nonconformists would be hard to find, and what emerged from the 2001 meeting was symbolic—The Manifesto for Agile Software Development—signed by all participants. We called ourselves the Agile Alliance.

Alistair Cockburn 最初的担忧反映出了许多参与者的想法：“我个人并不指望这群敏捷主义者会就任何实质性问题达成一致。”但他的会后感受也得到了认同：“就我个人而言，我对宣言的最终措辞感到高兴。所以，我们确实就一些实质性问题达成了一致。”

Alistair Cockburn’s initial concerns reflected the thoughts of many participants: “I personally didn’t expect this particular group of agilists to ever agree on anything substantive.” But his post-meeting feelings were also shared: “Speaking for myself, I am delighted by the final phrasing [of the Manifesto]. So, we did agree on something substantive.”

敏捷宣言由四个主要价值观陈述和 12 条原则组成，例如“简单——最大限度地减少未完成工作量的艺术——至关重要。” ⁹这些原则在接下来的几个月里通过 Ward 的 wiki 和电子邮件进行了讨论。我们在两天内就四个价值观及其措辞达成了一致。然而，让 17 个人决定并措辞 12 条更冗长的原则的过程进展缓慢——花了几个月的时间。

The Agile Manifesto consists of four primary value statements and 12 principles, such as “Simplicity—the art of maximizing the amount of work not done—is essential.”⁹ The principles were hashed out over the next several months via Ward’s wiki and email. We agreed on four values, and their wording, in two days. Getting 17 people to decide on and wordsmith the 12 wordier principles, however, went slowly—several months.

9.所有 12 条原则均可在http://agilemanifesto.org/principles.html找到。

9. All 12 principles can be found at http://agilemanifesto.org/principles.html.

在为期两天的会议结束时，鲍勃·马丁开玩笑说他即将发表“感性”言论。尽管他的话语中带着幽默，但几乎没有人不同意鲍勃的观点——我们都感到很荣幸能与一个拥有一套兼容价值观的团队一起工作，这套价值观基于信任和尊重。我们希望提倡以人为本的管理。从本质上讲，我认为敏捷主义者关心的是“感性”的东西——通过建立一个以人为本的环境向客户提供优质的产品——在这种环境中，心态是第一位的，方法和方法论紧随其后。

At the close of the two-day meeting, Bob Martin joked that he was about to make a “mushy” statement. But while his words were tinged with humor, few disagreed with Bob’s sentiments—that we all felt privileged to work with a group who held a set of compatible values, a set of values based on trust and respect. We wanted to promote people-centered management. At the core, I believe agilists are about “mushy” stuff—about delivering great products to customers by building an environment where people matter—where mindset comes first, and methods and methodology follow.

敏捷运动并非反对方法论；事实上，我们中的许多人都希望恢复方法论一词的可信度。我们希望恢复平衡。我们支持建模，但不会将一些图表归档到布满灰尘的公司存储库中。我们支持文档，但不会将数百页从未维护且很少使用的大部头文档归档。我们进行规划，但认识到在动荡的环境中规划的局限性。那些将 XP 或 Scrum 或任何其他敏捷方法论的支持者称为“黑客”的人既不了解方法论，也不了解黑客一词的原始定义。（Highsmith，2001 年）

The Agile movement is not anti-methodology; in fact many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never maintained and rarely used tomes. We plan but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or Scrum or any of the other Agile Methodologies as “hackers” are ignorant of both the methodologies and the original definition of the term hacker. (Highsmith, 2001)

沃尔特·艾萨克森 (Walter Isaacson) (2021) 在他的《密码破译者》一书中讲述了詹妮弗·杜德纳 (Jennifer Doudna) 和 CRISPR 发现的故事，正是这项生物技术让辉瑞和 Moderna 能够如此迅速地开发出针对 COVID-19 的疫苗。在推进 CRISPR 基因编辑技术的竞赛中，杜德纳和其他科学家进行了无休止的合作，分享他们对基因、DNA 和 RNA 的了解，以服务于医学界和患者。当然，同一批参与者之间的竞争也同样激烈，特别是在争夺先发表论文和获得专利的竞赛中。几年后，随着科学家们共同努力开发 COVID-19 疫苗，他们的合作更加深入。志同道合的竞争对手（无论是科学家还是软件开发人员）之间的合作，可能为 21 世纪初的挑战提供最佳解决方案。

In his book The Code Breakers, Walter Isaacson (2021) tells the story of Jennifer Doudna and the discovery of CRISPR, the biotechnology that enabled Pfizer and Moderna to develop their vaccines for COVID-19 so rapidly. In the race to advance CRISPR’s gene editing technology, Doudna and other scientists collaborated endlessly, sharing what they had learned about genes, DNA, and RNA to be of service to the medical community and patients. Of course, there was equally intense competition among the same players, especially in the races to publish first and to obtain patents. The scientists’ collaboration was heightened a few years later as the community worked together to develop a COVID-19 vaccine. Collaboration of like-minded competitors, whether scientists or software developers, may offer the best solutions to the challenges of the early twenty-first century.

在 Snowbird 会议期间，与会者分享了各自方法的理念和细节。我们发现了差异，但也发现了惊人的相似之处。毫无疑问，这次合作产生了将对世界产生深远而持久影响的成果。毫无疑问，我们会在会议结束后展开竞争，就像 CRISPR 科学家一样。我们中的一些人竞相出版有关敏捷主题的新书。

During the meeting at Snowbird, the attendees shared philosophies and details about each of their approaches. We discovered differences, but amazing similarities as well. There was no doubt that this collaboration produced a result that would have a profound and lasting impact on the world. There was also no doubt that we would leave the meeting and compete, just as the CRISPR scientists did. Several of us raced to publish new books on agile topics.

在一封电子邮件中，阿利斯泰尔·科克伯恩（Alistair Cockburn）提醒我注意一个事件，该事件有助于解释 Snowbird 会议的同事关系和协作精神：

In an email, Alistair Cockburn reminded me about an incident that helps explain the collegiality and collaboration of the Snowbird meeting:

有一次，我们聊着聊着，想知道鲍勃·马丁为什么邀请史蒂夫·梅勒，因为他看起来不像是个轻量级方法论者。史蒂夫自我介绍说：“嗨，我是史蒂夫·梅勒，我是一名间谍。”我们所有人都瞪大了眼睛。就像，哦天哪，你说得对。

At some point we were talking, wondering why Bob Martin had invited Steve Mellor because he didn’t appear to be a light methodologist. Steve introduces himself, “Hi, I’m Steve Mellor and I’m a spy,” and all of our eyes got big. Like, oh my gosh, you said it.

然后有一次我和 Ron [Jeffries] 与史蒂夫交谈，坦白说我们不喜欢他的东西。是的。因为他有很多图纸。神奇的是，我们没有攻击，而是开始问问题，比如“你之后做什么？你为什么要这样做？”他说，“嗯，我的目标是从图片中按下按钮，然后代码就出来了。” Ron 说，“是的，但你必须维护代码，而图片都是不同步的。”他说，“不，不，不，你维护图片。你永远不应该再碰代码了。” Ron 说，“所以你的意思是图片是源语言。”他说，“是的。” Ron 和我都说：“我们不关心源代码语言是什么。我不在乎它可能是图片，只要我不需要在两个地方维护它就行。”史蒂夫说，“这就是我的意思。”我说：“好吧，是的，我们都同意。虽然我们不认为你能做到，但如果这是你的意图，我们对此没有任何异议。”

Then there was this one particular moment with Ron [Jeffries] and me talking to Steve, and we frankly don’t like his stuff. Right. Because he’s got lots of drawings. The magical thing was we didn’t attack, but began to ask questions, like, “What do you do after? Why do you do this?” And he said, “Well, my goal is from the pictures you push a button, and the code comes out.” Ron says, “Yeah, but then you have to maintain the code and the pictures are all out of sync.” And he goes, “No, no, no, you maintain the pictures. You should never touch the code again.” Ron says, “So you mean that the pictures are the source language.” He goes, “Yeah.” And Ron and I both go: “We don’t care what the source code language is. It could be pictures for all I care as long as I don’t have to maintain it in two places.” And Steve goes, “That’s what I’m saying.” I go, “Well, yeah, we’re all onboard with that. Like, we don’t think you can do it, but if that’s your intention, we don’t have any problems with the intention.”

突然间，我们都站到了桌子的同一边；突然间，我们达成了一致。我们不同意他目前的技术是否能达到目的，但他的意图与我们是一样的。突然间，我们达成了一项重大共识，而之前我们存在很大分歧。所以，你知道，发生的那种神奇的事情，就是我所说的非常慷慨的倾听，慷慨地倾听，在大多数会议中你都看不到。

And suddenly we’re all on the same side of the table; suddenly we’re in agreement. We don’t agree his current techniques get there, but his intention is the same as our intention. Suddenly, we had a big agreement where we’d had a big disagreement before. So that kind of magic, you know, what happened, was what I called a very generous form of listening, listening with generosity, you don’t see in most meetings.

像这样的交流使得所有 17 位与会者同意最终的敏捷宣言价值观声明。

Exchanges like this were responsible for all 17 attendees agreeing to the final Agile Manifesto value statements.

具有讽刺意味的是，一群反传统的技术人员发起了一场运动，其基本信念是“个人及其互动”对于成功至关重要。

It’s somewhat ironic that an iconoclastic bunch of techies launched a movement based on a fundamental belief that “individuals and their interactions” was paramount to success.

敏捷宣言会议反映了这一信念，因为它不是来自一个有明确、期望结果的正式议程，而是来自一个促进创新和惊喜的协作、自组织环境。这可能是许多组织在“做”敏捷和“成为”敏捷之间缺失的一环，尤其是在中层管理和高管层。敏捷团队努力协作（每日站立会议、回顾、初始阶段），这对于跨职能团队成员来说并非易事。有多少管理和执行会议遵循了这一示例？第 7 章中的两个客户故事将探讨管理层对采用敏捷实践的承诺如何影响组织向敏捷转型的成功。

The Agile Manifesto meeting mirrored that belief, as it emerged not from a formal agenda with stated, desired outcomes, but rather from a collaborative, self-organizing environment that fostered innovation and surprise. This may be a missing link in many organizations between “doing” agile and “being” agile, especially at mid-management and executive levels. Agile teams work hard at collaboration (daily stand-ups, retrospectives, inceptions), which isn’t an easy feat with cross-functional team members. How many management and executive meetings follow this example? Two client stories in Chapter 7 will examine how management’s commitment to adopting agile practices makes a difference in the success of an organization’s transition to agility.

20 世纪 90 年代末，统一建模语言 (UML) 因将各种图表绘制实践整合在一起而变得流行。但就像 20 世纪 80 年代出现的巨型方法论一样，UML 被纳入最新的巨型方法论——即 Rational Unified Process (RUP)。

DURING THE LATE 1990s, Unified Modeling Language (UML) became popular as it brought a variety of diagramming practices together. But, like the emergence of Monumental Methodologies in the 1980s, UML became subsumed into the newest Monumental Methodology—namely, the Rational Unified Process (RUP).

除了包含 UML 图之外，RUP 还包括流程指南、可以解释为迭代的生命周期和在线知识库。随着敏捷方法的流行，RUP 的支持者认为它们的生命周期确实是迭代的，您可以简化小型项目的流程。不幸的是，对于他们来说，这两个假设对于敏捷社区来说都是不可行的。大型 IT 组织继续将 RUP 生命周期用作瀑布方法，并且保留“内容”比冒险简化更容易。敏捷实践者继续将 RUP 排除在敏捷甚至迭代方法之外。

In addition to incorporating UML diagrams, RUP included process guides, a life cycle that could be interpreted as iterative, and an online knowledge base. As agile approaches became popular, RUP proponents argued their life cycle was indeed iterative and you could simplify the process for smaller projects. Unfortunately for them, neither of these assumptions proved viable to the agile community. Large IT organizations continued to use the RUP life cycle as a waterfall approach, and it was too easy to keep “stuff” rather than take a chance with simplification. Agile practitioners continued to exclude RUP as an agile, or even iterative, methodology.

在一个 XP 讨论组中，讨论供应商如何推广他们的方法，以适应较小的项目，Larry Constantine 说道：

In an XP discussion group about vendors promoting their methodologies as tailored to smaller projects, Larry Constantine chimed in:

但是，通过 RUP 进行 XP 在我看来有点像购买一辆昂贵的 18 轮搬运车，然后扔掉拖车，拆掉驾驶室，将柴油车换成经济型 4 缸发动机，并增加额外的座位，这样就可以拥有一辆轻便的小型汽车，可以带着孩子和杂货快速在城里转悠。如果您必须付出代价，也许这种方法总比什么都不做要好，但似乎仅仅通过 XP 进行 XP 会更便宜、更有效率。

However, doing XP by way of RUP strikes me as a little like buying an expensive 18-wheel moving van, then throwing away the trailer, chopping down the cab, swapping the diesel for an economical 4-banger, and adding extra seats to have a sprightly little runabout for getting quickly around town with the kids and the groceries. If you must pay the price, perhaps this approach is better than nothing, but it seems that doing XP simply by doing XP would be cheaper and more efficient.

敏捷组织

Agile organizations

《敏捷宣言》一经发布，其势头便迅速增长，其推动力包括宣言作者发起的敏捷联盟、新书的出版、持续的极限编程会议以及越来越多的论文。

Once the Agile Manifesto was released, momentum grew rapidly, driven by the Manifesto authors launching the Agile Alliance, new books, continuing Extreme Programming conferences, and a growing blizzard of papers.

在宣言会议召开之前，我为《软件测试与质量工程》（Highsmith，2000）撰写了封面文章“退休生命周期恐龙” 。2001 年秋天，Martin Fowler 和我为《软件开发》杂志撰写了封面文章《敏捷宣言》（Fowler and Highsmith，2001），如图5.1所示。最近看这本杂志时，我被副标题所震撼，其中包括“17 位无政府主义者同意……”这句话。同年秋天，Alistair Cockburn 和我在《IEEE 计算机》（Highsmith and Cockburn，2001）上撰写了《敏捷软件开发》。与此同时，其他人正在撰写有关 Scrum、XP 和 DSDM ¹¹敏捷实践的文章。Alistair 和我成为 Addison-Wesley 敏捷系列的联合编辑，到 2010 年，该系列已出版了十几本书。

Just prior to the Manifesto meeting, I wrote the cover article, “Retiring Lifecycle Dinosaurs,” in Software Testing & Quality Engineering (Highsmith, 2000). In the fall of 2001, Martin Fowler and I wrote the cover article in Software Development magazine, “The Agile Manifesto” (Fowler and Highsmith, 2001), pictured in Figure 5.1. Looking at this magazine recently, I was struck by the subtitle, which included the phrase “17 anarchists agree on… .” That same fall, Alistair Cockburn and I wrote “Agile Software Development,” in IEEE Computer (Highsmith and Cockburn, 2001). Meanwhile, others were writing about Scrum, XP, and DSDM¹¹ agile practices. Alistair and I became co-editors of Addison-Wesley’s Agile Series, which featured a dozen books by 2010.

11. DSDM 最初代表“动态系统开发方法”。然而，敏捷商业联盟现在仅使用 DSDM 作为名称。

11. DSDM originally stood for “Dynamic Systems Development Methodology.” However, the Agile Business Consortium now uses just DSDM as the name.

《敏捷宣言》发布后的几年里，出现了多个组织来推广敏捷方法、方法论和思维方式：敏捷联盟、敏捷会议、敏捷项目领导网络 (APLN)、Scrum 联盟和 Scrum.org。

In the years after the release of the Agile Manifesto, several organizations formed to promote agile methods, methodologies, and mindset: The Agile Alliance, Agile Conferences, the Agile Project Leadership Network (APLN), the Scrum Alliance, and Scrum.org.

敏捷联盟于 2001 年底正式成立，当时只有不到 50 名成员，预算高达 7,350 美元，自成立以来，该联盟的规模确实在不断扩大。截至 2021 年，该联盟拥有超过 8,500 名成员，时事通讯受众超过 70,000 人，运营预算超过 400 万美元。自 2001 年以来，敏捷联盟一直在为人们和组织提供信息和激励，帮助他们探索、应用和扩展《敏捷宣言》中概述的价值观、原则和实践。

THE AGILE ALLIANCE, officially chartered in late 2001 with fewer than 50 members and a huge budget of $7,350, has certainly grown since its founding. As of 2021, the Alliance had more than 8,500 members, a newsletter audience of 70,000-plus, and an operating budget of more than $4 million. Since 2001, the Agile Alliance has been informing and inspiring people and organizations as they explore, apply, and expand the values, principles, and practices outlined in the Agile Manifesto.

在撰写《敏捷宣言》时，与会者开始将我们自己称为敏捷联盟，但当时并没有正式的组织。2001 年，组织问题不断出现，最终于 2001 年 11 月 19 日在芝加哥召开了创始董事会会议。一些《宣言》作者希望加入正式联盟，其他人则不然。此次会议的与会者包括 Mike Beedle、Ron Crocker、Jim Highsmith、Bob Martin、Ken Schwaber、Mary Poppendieck、Grady Booch、Steven Fraser、Chet Hendrickson、Jacqui Horwitz、Jon Kern、Linda Rising、Dave Thomas 和 Martin Fowler。12^我们的目标是发展这项运动，但很少有人知道它会发展到何种程度。

While writing the Agile Manifesto, the attendees began referring to ourselves as the Agile Alliance, but there was no formal organization. During 2001, organizational issues were churning that resulted in the founding board meeting on November 19, 2001, in Chicago. Some Manifesto authors wanted to participate in the formal Alliance, others didn’t. The attendees at this meeting included Mike Beedle, Ron Crocker, Jim Highsmith, Bob Martin, Ken Schwaber, Mary Poppendieck, Grady Booch, Steven Fraser, Chet Hendrickson, Jacqui Horwitz, Jon Kern, Linda Rising, Dave Thomas, and Martin Fowler.¹² Our objective was to grow the movement, but few had any idea about how widespread it would become.

12.在为本书做研究时，我在存档文件中找到了敏捷联盟的原始董事会会议记录、预算和章程的副本。我将这些转发给了现任联盟工作人员。

12. In researching for this book, I found copies of the original board minutes, budgets, and constitution for the Agile Alliance in my archived files. I forwarded these to the current Alliance staff.

如今，跨国敏捷联盟提供教育材料（书籍、研究、博客、聚会）、对当地活动和团体的支持，以及其基石——大型会议。除了由代表 7 个国家的 10 名成员组成的多元化志愿者委员会（2022 年）外，它现在还拥有一名董事和其他带薪员工。敏捷联盟有一位董事总经理，任职时间超过 15 年。菲尔·布洛克 (Phil Brock) 任职 13 年，于 2020 年辞职。

Today, the multinational Agile Alliance provides educational materials (books, research, blogs, meetups), support for local events and groups, and its cornerstone—large conferences. In addition to a diverse volunteer board (in 2022) of 10 members representing 7 countries, it now has a director and other paid staff. The Agile Alliance has had a managing director for more than 15 years. Phil Brock served for 13 years before he resigned in 2020.

尽管 XP 会议已经举办了好几年，但截至 2002 年初，敏捷会议仍未出现。2002 年夏天，Alistair Cockburn 和我举行了一次“餐巾纸背面”会议，概述了敏捷会议的面貌。Ken Schwaber 随后加入了计划，我们决定于 2003 年 6 月 25 日至 28 日在盐湖城举行首届会议，并确定了会议地点。我从盐湖城搬到了亚利桑那州的弗拉格斯塔夫，让 Alistair 负责大部分计划工作（他一直让我忘记我放弃他）。Todd Little 介入并成为会议的早期和定期组织者。

While there had been an XP conference for several years, as of early 2002 no Agile conference was on the horizon. In the summer of 2002, Alistair Cockburn and I had one of those “back of the napkin” meetings to outline what an Agile conference would look like. Ken Schwaber then joined in the planning, and we decided on June 25–28, 2003, in Salt Lake City, as the inaugural dates and secured a venue. I moved from Salt Lake City to Flagstaff, Arizona, leaving Alistair with much of the planning (he’s never let me forget my bailing out on him). Todd Little stepped in and became an early and regular organizer for the conferences.

Todd 在推动敏捷方面发挥了重要作用，他是公司里的实施者，也是行业活动的组织者。虽然 Alistair 和我发起了这次会议，但 Todd 知道如何真正组织一次会议。我在 1998 年旧金山的一次软件开发会议上遇到了 Todd，他1999 年，他邀请我去他的内部 Landmark Graphics（哈里伯顿的一部分）会议上发言。2002 年初秋，Alistair、Todd 和我参加了在波士顿举行的 Cutter Consortium 峰会，我们在那里招募了 Todd（这并不难）来帮助组织第一届敏捷会议。Todd 后来主持了许多敏捷会议，是敏捷联盟的董事会成员，并担任敏捷项目领导网络 (APLN) 的联合创始人和董事会成员。宣言发起了敏捷运动，但像 Todd 这样的人的辛勤工作和奉献精神确保了运载火箭进入轨道。

Todd was instrumental in promoting agile, as an implementer in his companies and in organizing industry events. While Alistair and I initiated the conference, Todd knew how to actually organize one. I met Todd during a 1998 Software Development conference in San Francisco, and he invited me to speak at his internal Landmark Graphics (part of Halliburton) conference in 1999. During the early fall of 2002, Alistair, Todd, and I attended the Cutter Consortium’s Summit conference in Boston, where we recruited Todd (it wasn’t hard) to help organize the first Agile conference. Todd went on to chair many Agile conferences, was an Agile Alliance board member, and served as a co-founder and board member of the Agile Project Leadership Network (APLN). The Manifesto launched the agile movement, but the hard work and dedication of individuals like Todd ensured that the launch vehicle achieved orbit.

根据笔记和记忆，托德通过电子邮件发送了有关波士顿会议的更多详细信息。

From notes and memory, Todd emailed additional details about the meeting in Boston.

一天晚上，我们一群人去了麻省理工学院博物馆，这是卡特会议组织的一次郊游活动的一部分。在那里我第一次遇到了阿利斯泰尔。我们从一开始就相处得很好，当我们一行人走回酒店时，我们最终在科学奇迹酒吧和烧烤店停了下来。喝了几杯酒后，阿利斯泰尔拿出几张纸，上面有一些图画。他把这些纸传给大家，问大家更喜欢哪一个作为他正在筹划的敏捷会议的标志。当然，这激起了我的兴趣，因为过去几年我在组织 Landmark Graphics 全球开发者会议方面有相当多的经验。

One evening a group of us went to the MIT museum as part of an outing organized by the Cutter Conference. It was there I first met Alistair. We hit it off quite well from the get-go, and as our group was walking back to the hotel we ended up stopping at the Miracle of Science Bar & Grill. After a couple of drinks Alistair pulled out a couple of pieces of paper with some drawings on them. He passed them around and asked the group which we preferred as a logo for an Agile conference he was planning. Of course, this piqued my interest as I had quite a bit of experience organizing Landmark Graphics Worldwide Developer conferences over the past few years.

在快速评估了徽标选项后，谈话很快转向了我们在内部会议上所做的一些可能引起人们兴趣的事情。我首先解释了我们为建立社区和将人们聚集在一起所做的工作。我们公司有一句谚语：“除非你把人整合起来，否则你怎么能构建集成的软件解决方案？”当然，这对 Alistair 来说是天籁之音，因为他长期以来一直是软件开发人性化的倡导者。

After a quick assessment of the logo options, the conversation quickly moved towards some of the things we had done at our internal conferences that might be of interest. I started by explaining what we had done to build our community and to bring people together. We had a saying in our company about “How can you build integrated software solutions unless you integrate the people?” Of course, this was music to Alistair’s ears as he had long been an advocate for the human side of software development.

第二天晚上，我们进行了一次愉快的交谈，并在餐巾纸背面记录了勉强够用的文档（图 5.2）。我们就总体愿景达成了一致，并与 Alistair 建立了深厚的友谊。虽然餐巾纸刚好够我们开始工作，但 Alistair 后来为会议创建了一份章程文件，这对我们工作的开展非常有帮助。

The next evening, we had a great chat along with barely sufficient documentation on the back of a napkin (Figure 5.2). We agreed on a general vision and kicked off a great friendship with Alistair. While the napkin was just enough to get things rolling, Alistair did later create a charter document for the conference which was quite helpful to anchor our efforts.

第一次敏捷开发大会旨在会议期间和会后培养和发展敏捷社区（图 5.3显示了会议邀请函封面）。设计包括传统的演讲者演示，但也指导了关于关键主题的非正式会议。敏捷是新事物，在空气中产生了一种兴奋的嗡嗡声。第一次会议取得了成功——计划和讨论得到了好评。大约有 250 人参加，并赚了一点钱。最后一点对 Alistair、Ken Schwaber 和我来说尤其重要，因为我们保证会弥补任何不足。Todd 主持了接下来的几次会议，在接下来的几年里，出席人数增长到 300 人，然后随着 XP 和敏捷会议的合并，出席人数增长到 700 人，然后增加到 1,100 人。在疫情爆发前的几年里，会议出席人数上限为 2,500 人（见图5.4）。与任何由固执己见的个人领导的快速发展的运动一样，在增长期间也有一些自尊心和感情受到伤害。但效果非常显著，伤痕都愈合了。据我所知，没有骨折。

The first Agile Development Conference was designed to foster and grow an agile community during and after the conference (Figure 5.3 shows the conference invitation cover). The design included traditional speaker presentations, but also guided informal sessions on key topics. Agile was new, generating a buzz of excitement in the air. This first conference was a success—programs and discussions received good reviews. About 250 people attended, and it made a little profit. The last point was particularly relevant for Alistair, Ken Schwaber, and me, as we had guaranteed to cover any shortfall. Todd chaired the next several conferences as attendance grew to 300 over the next couple of years, and then to 700 as the XP and Agile conferences were merged, and then ramped up to 1,100. In the years before the pandemic, conference attendance was capped at 2,500 (see Figure 5.4). As with any fast-growing movement led by opinionated individuals, there were a few bruised egos and feelings during the growth period. However, the results were spectacular, and bruises healed. There were no broken bones that I know of.

第一次 Agile 会议两年后，XP 会议在经过激烈谈判后，被纳入 Agile 会议，并由 Agile Alliance 赞助。不过，该联盟继续赞助单独的 XP 会议，以及越来越多的其他会议。

Two years after the first Agile conference, the XP conference was blended into the Agile conference (after intense negotiation) under the auspices of the Agile Alliance. However, the Alliance continued to sponsor separate XP conferences, and a growing number of others.

敏捷项目领导网络（后来被称为敏捷领导网络）是在三次会议期间成立的。第一次是我在 2004 年盐湖城敏捷开发大会上发起的一次即席会议，目的是评估对独立于敏捷联盟的项目管理小组的兴趣。随后，2004 年 10 月在芝加哥举行了第二次会议。2005 年 1 月下旬，我们在华盛顿州雷德蒙德的微软园区召开了第三次会议。在这些会议上，以及在雅虎群组的持续讨论中，我们讨论了项目经理和项目管理在敏捷开发中的作用，然后成立了^APLN。14

THE AGILE PROJECT Leadership Network (later named the Agile Leadership Network) was launched over the course of three meetings. The first was an impromptu meeting that I initiated at the 2004 Agile Development Conference in Salt Lake City to gauge the interest in a project management group separate from the Agile Alliance. This was followed by a second meeting in Chicago in October 2004. In late January 2005, we convened the third meeting at the Microsoft campus in Redmond, Washington. At these meetings, as well as in ongoing discussions on a Yahoo group, we discussed the role of project managers and project management in agile development and then formed the APLN.¹⁴

14.托德·利特尔 (Todd Little) 补充了我的记忆以及有关这些创始会议的旧电子邮件交流，但任何错误均由我独自承担。

14. Todd Little added to my memory and old email exchanges about these founding meetings, but any errors are mine alone.

雷德蒙德的与会者包括 Sanjiv Augustine、Bob Wysocki、Preston Smith、Christopher Avery、Todd Little、Donna Fitzgerald、David Andersen、Ole Jepson、Alistair Cockburn、Doug DeCarlo 和 Jim Highsmith。这些与会者拥有软件开发和项目方面的各种背景管理。例如，普雷斯顿·史密斯 (Preston Smith) 是一位作家 (Smith and Reinertsen, 1997) 和制成品顾问。那次会议的结果是最终确定了《相互依存宣言》和 APLN 的初步组织。在那次会议之后，其他为组织过程做出贡献的人包括迈克·科恩 (Mike Cohn)、波莉安娜·皮克斯顿 (Pollyanna Pixton)、洛厄尔·林德斯特罗姆 (Lowell Lindstrom) 和肯特·麦克唐纳 (Kent MacDonald)。

Attendees in Redmond were Sanjiv Augustine, Bob Wysocki, Preston Smith, Christopher Avery, Todd Little, Donna Fitzgerald, David Andersen, Ole Jepson, Alistair Cockburn, Doug DeCarlo, and Jim Highsmith. These attendees had a range of backgrounds in software development and project management. For example, Preston Smith was an author (Smith and Reinertsen, 1997) and consultant on manufactured products. The results of that meeting were the finalization of the Declaration of Interdependence and preliminary organization of the APLN. Others contributing to the organizational process after that meeting included Mike Cohn, Pollyanna Pixton, Lowell Lindstrom, and Kent MacDonald.

雷德蒙德会议仿照敏捷宣言会议（图 5.5）。当时，敏捷社区中存在这样一种观点：“我们不需要任何该死的项目经理”。雷德蒙德小组不同意：我们认为项目管理必不可少，但项目经理应该具有敏捷思维。我们需要的项目经理首先善于管理人员，而不是管理任务。这场争论一部分是术语，一部分是重新定义项目经理的角色。是否需要更改“项目经理”的名称以强调新事物？XP 团队争论是否需要任何项目管理，而其他人则选择更改名称以配合角色的变化。奇怪的是，我从未听到过关于更改程序员/软件开发人员名称的类似争论，尽管 XP 重新定义了该角色。

The Redmond meeting was modeled after the Agile Manifesto conclave (Figure 5.5). At the time, there was sentiment in the agile community that “We don’t need any darn project managers.” The Redmond group didn’t agree: We thought project management was essential, but project managers should have an agile mindset. We needed project managers who were adept at managing people first, rather than tasks. Part of this debate was terminology, part was redefining roles for project managers. Did the “project manager” name need to change to drive home the point something was new? The XP contingent debated the need for any project management, while others opted for a name change to accompany the role change. Strangely enough, I never heard a similar debate about changing the programmer/software developer name, even though XP redefined that role.

在最初的两到三年里，APLN 会议讨论了我们成员的计划目标和行动计划。我们最大的成功案例是建立了地方分会。几位董事会成员编写了一本“食谱”来协助地方团体，而全国 APLN 则提供了法律基础。2000 年代后期成立的几个地方团体仍在继续活动——在旧金山湾区和休斯顿。

In the first two to three years, APLN meetings discussed program goals and action initiatives for our members. Our biggest success story was establishing local chapters. Several board members wrote a “cookbook” to assist local groups, and the national APLN provided a legal foundation. Several local groups that were established in the late 2000s continue still—in the San Francisco Bay area and Houston.

一场持续两年的辩论是，是否要创建敏捷项目管理认证计划。当时，项目管理协会 (PMI) 运行着一个不包括敏捷的传统认证计划。Scrum 组织有针对 Scrum 角色的认证计划。但非 Scrum 敏捷社区继续争论认证的有效性。APLN 董事会分为三派：(1) 支持认证并对现有认证模型相当满意的人​​；(2) 一般反对认证的人，理由是敏捷本身无法认证；(2) 中间派，他们愿意考虑认证，但对他们所谓的“认证 1.0”感到不满意。他们担心的是，传统的认证模型是基于对相对静态的知识体系的学习验证，但这与敏捷的本质相悖。董事会批准了一个小组调查认证计划，但最终投票决定放弃进一步的努力。

An ongoing debate—it lasted for two years—was whether to create an Agile Project Management certification program. At that point, the Project Management Institute (PMI) ran a traditional certification program that did not include agile. The Scrum organization had certification programs for the Scrum roles. But the non-Scrum agile community continued to debate the efficacy of certification. The APLN board was divided into three contingents: (1) those who supported certification and were quite comfortable with existing certification models, (2) those who generally opposed certification on the basis that agility was not inherently certifiable, and (2) the group in the middle, who were willing to consider certification but were not comfortable with what they called “certification 1.0.” The concern was that traditional certification models were based on validation of learning against a relatively static body of knowledge, yet that was at odds with the nature of agility. The board sanctioned a group to investigate a certification program, but in the end voted to abandon further efforts.

在 APLN 和更广泛的敏捷社区中，认证讨论归结为顺从与客户压力之间的争论。鉴于《敏捷宣言》是由 17 位不顺从者创建的，许多人认为认证是终极的顺从，但也是无效的。但是，认证支持者认为，敏捷方法关注客户，许多公司和个人都希望获得某种程度的能力认证。您是给客户他们想要的东西，还是您认为他们应该想要的东西？虽然许多表面争论集中在认证的有效性或无效性问题上，但更大的问题往往被忽略。这个困境体现了一个悖论，认证问题的答案取决于此：如果我们只给客户他们想要的东西，那么这些要求会成为新产品创意的唯一来源吗？我们是否满足了客户的要求，即使我们认为这是错误的？在我们这个快速发展的世界，领导技能之一就是“驾驭悖论”——将问题（有解决方案）与悖论（只有随时间而变的解决方案）区分开来。认证似乎就是这些悖论之一。

The certification discussions, within the APLN and the wider agile community, boiled down to a debate between conformity and customer pressure. Given that the Agile Manifesto was created by 17 nonconformists, certifications were considered the ultimate conformity by many, as well as ineffective. But, argued the certification supporters, agile methods focus on customers, and a great many companies and individuals want some measure of capability certification. Do you give customers what they ask for, or what you think they should want? While much of the surface debate centered on the issue of certification’s effectiveness or ineffectiveness, the larger issue was often missed. This quandary exemplifies a paradox on which the answer to the certification question depended: If we only give customers what they ask for, do those asks become the sole source of new product ideas? Do we give customers what they ask for, even if we think it’s wrong? One of the leadership skills required in our fast-moving world is the “riding paradox”—separating problems, for which there are solutions, from paradoxes, for which there are only resolutions that will change with time. Certification seems to be one of these paradoxes.

APLN 又持续了几年，但从未在更广泛的项目管理社区中获得关注。PMI 于 2011 年开始提供敏捷项目管理认证。APLN 现在正在与敏捷联盟、PMI 和各种 Scrum 组织竞争。APLN 赞助了几次地方会议，但与敏捷联盟的谈判联盟主办敏捷会议的项目管理部分未能成功。由于缺乏认证计划或大型会议的资助机制，国家 APLN（当时的敏捷领导力网络）无法生存。

The APLN continued for several more years, but never gained traction in the wider project management community. PMI began offering an Agile Project Management certification in 2011. The APLN was now competing with the Agile Alliance, PMI, and the various Scrum organizations. The APLN sponsored several local conferences, but negotiations with the Agile Alliance to host the project management part of the Agile conference were unsuccessful. Without the funding mechanism of either a certification program or a major conference, the national APLN (by then the Agile Leadership Network) didn’t survive.

敏捷生态系统

Agile ecosystems

多年来，人们对于“敏捷”这一笼统术语和 Scrum 和 XP 等具体方法论一直存在混淆。为了消除这种混淆，在“敏捷宣言”会议召开之前，我开始考虑编写一本关于敏捷方法的调查书籍。在“宣言”会议期间，我采访了第二本书的参与者，这本书最终定名为《敏捷软件开发生态系统》（ASDE；Highsmith，2002 年）。

Over the years, there had been confusion over the umbrella term agile and specific methodologies such as Scrum and XP. To head off the confusion, prior to the Agile Manifesto gathering, I began thinking about a survey book on agile methods. During the Manifesto meeting, I interviewed participants for this second book, which was ultimately titled Agile Software Development Ecosystems (ASDE; Highsmith, 2002).

ASDE一书概述了宣言会议中所代表的方法论。书中还采访了敏捷领域的杰出人物：Kent Beck、Ken Schwaber、Martin Fowler、Ward Cunningham 和 Alistair Cockburn。Tom DeMarco 撰写了一篇精彩的前言，其中有以下文字：

The ASDE book surveyed the methodologies represented in the Manifesto meeting. It included interviews with agile luminaries: Kent Beck, Ken Schwaber, Martin Fowler, Ward Cunningham, and Alistair Cockburn. Tom DeMarco wrote a wonderful foreword that included these words:

九十年代是 IT 流程化的十年。我们拜倒在 CMM 和 ISO 面前。我们不仅追求软件构建方式的完美，还追求完全的可预测性。我们得出结论，仅仅把事情做好是不够的，我们还必须“做决定”：提前明确我们打算做什么，然后准确执行。不多也不少。我们决心（用 CMM 术语来说）“规划工作，并按计划开展工作”。

The nineties were the Decade of Process for IT. We prostrated ourselves before the CMM and ISO. We sought not just perfection in the way we built software, but total predictability. We concluded that it wasn’t enough just to do things right, we also had to “call our shot”: to say in advance exactly what we intended to do, and then do exactly that. Nothing more and nothing less. We were determined (in CMM terms) to “plan the work and work the plan.”

如今，繁琐流程的时代已经结束。正如 Jim Highsmith 所说，“精简才是王道”。为了优化速度和响应能力，我们需要精简流程。我们需要摆脱文书工作和官僚负担，消除无休止的代码检查，并投资于我们的员工，使他们能够明智地驾驭现代 IT 项目的混乱迷宫。这就是敏捷软件开发方法的起源。（Highsmith，2002 年，第xv - xvi页）

Today the era of fat process is over. As Jim Highsmith has said, “Thin is in.” To optimize speed and responsiveness, we need to put process on a diet. We need to shed paperwork and bureaucratic burden, eliminate endless code inspections, and invest in our people so they can steer themselves sensibly through the chaotic maze that is a modern-day IT project. This is the genesis of the Agile approaches to software development. (Highsmith, 2002, pp. xv–xvi)

对于每种方法，我都采访了关键人物——例如，XP 的 Kent Beck 和 Ward Cunningham，Scrum 的 Ken Schwaber。转录、编辑和获得这些采访的反馈是撰写本书最困难的部分，但也被证明对读者具有很高的价值。

For each methodology, I interviewed key players—for example, Kent Beck and Ward Cunningham for XP, Ken Schwaber for Scrum. Transcribing, editing, and getting feedback on these interviews was the single hardest part of writing this book, but also proved to be of high value to readers.

我使用生态系统这个术语来描述一种整体思维模式，它包括三个相互交织的组成部分——混沌^视角、协作价值观和原则，以及勉强够用的方法论——敏捷主义者这个术语用来指代敏捷方法论的支持者。

I used the term ecosystem to describe a holistic mindset that included three interwoven components—a chaordic¹⁵ perspective, collaborative values and principles, and a barely sufficient methodology—and the term agilists to identify those who are proponents of agile methodologies.

15. chaordic这个词是由 Dee Hock 创造的。

15. The word chaordic was coined by Dee Hock.

肯·施瓦伯 (Ken Schwaber) 曾说过一句很有意思的话，他在 20 世纪 90 年代曾担任 Advanced Development Methods 公司的首席执行官。他公司的产品 MATE（方法和工具专家）实现了其结构化方法的自动化。肯讲述了他与 Jeff Sutherland（Scrum 联合创始人）的一次对话：

One telling quip came from Ken Schwaber, who in the 1990s was CEO of Advanced Development Methods. His company’s product MATE (Methods and Tools Expert) automated its structured methodology. Ken related a conversation he had with Jeff Sutherland (co-creator of Scrum):

有一次 Jeff 问我，在所有这些方法论中（Coopers 的、IBM 的、我们自己的等等），我们用哪一种来构建我们的 MATE 产品？“没有，”我说。“如果我们使用其中任何一种，我们就会破产！”因此，我们与自己的开发人员坐下来，询问他们实际上做了什么，他们是如何工作的。答案是快速周转、不断发展的对象图、不断发展的自适应需求，以及一切都在不断变得更好。

At some point Jeff asked me, with all these methodologies—Coopers’, IBM’s, our own, etc.—which one did we use for building our MATE product? “None,” I said. “If we used any of them, we’d be out of business!” So, we sat down with our own developers and asked them what they actually did, how they worked. And the answers were quick turnaround, evolving object diagrams, adaptive requirements evolved, and that everything kept getting better and better.

敏捷方法

Agile methodologies

接下来的叙述反映了 2002 年我为ASDE进行这些采访时三种特定敏捷方法的状态。它们关注每种方法的哲学和贡献，因为从那时起方法和方法论已经发生了很大的变化。因此，当您阅读 Scrum 概述时，它提到 Scrum 已经使用了近 10 年，这段时间反映出这篇文章是在 2002 年写的。这些经过编辑的草图提供了一个基准，显示了这些方法在过去 20 年中发生了多大的变化（以及没有变化）^。16

These next narratives reflect the state of three specific agile methodologies in 2002 when I conducted these interviews for ASDE. They focus on the philosophies and the contributions of each since the methods and methodologies have evolved considerably since then. So, when you read the overview of Scrum and it mentions Scrum has been in use for nearly 10 years, that period reflects that this piece was written in 2002. These edited sketches provide a benchmark showing how much these methodologies have changed—and haven’t changed—over the last 20 years.¹⁶

16、这些草图是来自ASDE 的编辑版本。

16. These sketches are edited versions from ASDE.

SCRUM 以橄榄球中的 scrum 命名，最初由 Ken Schwaber 和 Jeff Sutherland 开发，后来与 Mike Beedle 等人合作。Scrum 提供了一个管理框架，将开发组织成 30 天的 Sprint 周期¹⁷，在此期间交付一组指定的待办事项功能。Scrum 的一个核心实践是使用每日站立式团队会议进行协调和整合。Scrum 已使用近 10 年，并已成功交付了各种产品。

SCRUM, NAMED FOR the scrum in rugby, was initially developed by Ken Schwaber and Jeff Sutherland, with later collaborations with Mike Beedle and others. Scrum provides a management framework that organizes development into 30-day Sprint cycles¹⁷ in which a specified set of backlog features is delivered. A core practice in Scrum is the use of daily stand-up team meetings for coordination and integration. Scrum has been in use for nearly 10 years and has been used to successfully deliver a wide range of products.

17 . 如今，周期越来越短，甚至是连续的。

17. Cycles are shorter or even continuous these days.

1996 年，肯·施瓦伯 (Ken Schwaber) 为Cutter IT Journal撰写了一篇题为“受控混乱：生活在边缘”的文章。即使在这个早期，肯也把对复杂性理论的理解带入了软件开发和项目管理中。

In 1996, Ken Schwaber wrote an article for Cutter IT Journal titled “Controlled Chaos: Living on the Edge.” Even at this early date, Ken brought an understanding of complexity theory to software development and project management.

Ken 是一位严谨、以流程为中心的方法论专家，他开始意识到日益详细和具体的方法论（充斥着过多的阶段、步骤、任务和活动）存在根本缺陷。“Scrum 方法的核心是相信大多数系统开发都有错误的哲学基础，”Ken 说。他断言，软件开发不是严谨方法论所假设的“定义过程”，而是一个“经验过程”。

Ken, an expert in rigorous, process-centric methodologies, began to realize the increasingly detailed and specific methodologies—overburdened with phases, steps, tasks, and activities—had a fundamental flaw. “The core of the Scrum approach is the belief that most systems development has the wrong philosophical basis,” Ken says. He asserts software development is not a “defined process,” as rigorous methodologies assume, but an “empirical process.”

在对工业过程控制的调查中，肯发现定义过程和经验过程之间的差异不仅巨大，而且需要完全不同的管理风格。定义过程主要借鉴“定义”输入到输出转换的基本物理和化学定律。定义过程可以重复多次，变化不大。经验过程不符合科学定律，因此无法始终如一地“重复”；因此，它需要不断监控和调整。“开发人员和项目经理被迫生活在谎言中——他们不得不假装他们可以计划、预测和交付，”肯说。但是，你可以用明确的监控标准来约束经验过程，并用持续的反馈机制来管理过程本身。

In his investigation of industrial process control, Ken discovered the differences between defined and empirical processes were not only profound, but also required a completely different management style. A defined process draws heavily on fundamental physical and chemical laws that “define” the transformation of inputs to outputs. Defined processes can be repeated time after time with little variation. An empirical process doesn’t conform to scientific laws, so it cannot be consistently “repeated”; hence, it requires constant monitoring and adaptation. “Developers and project managers are forced to live a lie—they have to pretend they can plan, predict, and deliver,” says Ken. You can, however, bound the empirical process with explicit monitoring criteria and manage the process itself with constant feedback mechanisms.

传统的项目管理实践认为项目是可预测的，偏离“计划”是由于执行不力。Scrum（和其他敏捷软件开发生态系统）认为工作是不可预测的，并相信人们在特定情况下会尽最大努力。因此，项目管理应强调沟通、协作、协调和知识共享。

Traditional project management practices assume projects are predictable and variations from the “plan” are caused by poor execution. Scrum (and other agile software development ecosystems) views work as unpredictable and trusts people are doing their best under the circumstances. Therefore, project management should emphasize communication, collaboration, coordination, and knowledge sharing.

定义的流程依赖于可重复性，而对于不断变化和缺乏公式化转换的流程来说，这是不可能实现的。经验性流程很快就会失控，因此成功的关键是通过每日 Scrum 会议和 Sprint Backlog 图表进行持续监控，同时促进解决复杂问题所需的创造力。

Defined processes depend on repeatability, an impossibility for processes besieged by constant changes and a lack of formulaic transformation. Empirical processes can spin out of control quickly, so the key to success is constant monitoring via the daily Scrum meeting and Sprint Backlog Graph, while at the same time facilitating the creativity required to solve complex problems.

Scrum 说：“做好这几件事，项目就会成功。”此外，“如果你不做好这几件事，无论你做好多少其他几百件事，你都不会成功。”

Scrum says, “Do these few things well, and projects will succeed.” Furthermore, “If you don’t do these few things well, it doesn’t matter how many other hundreds of things you do well, you won’t succeed.”

极限编程 (XP)在软件开发领域迅速流行起来，并触动了整个敏捷类别的神经。它的成功有几个原因。首先，它的受众是开发人员，世界上有大批开发人员厌倦了“方法论”的束缚。其次，随着互联网的出现，人们意识到需要一种兼顾速度、灵活性和质量的开发方法。第三，Kent Beck 是一位有效的推广者。第四，Kent 选择了一个很棒的名字——极限编程——它针对的是开发人员受众，并告诉世界其中有新的东西，有“极限”的东西。

EXTREME PROGRAMMING (XP) exploded onto the software development scene and hit a nerve that vaulted the entire agile category into the spotlight. Several reasons explain its success. First, its audience was developers, and there were legions of them in the world tired of “methodologies” getting in their way. Second, with the advent of the Internet, there was a perceived need for a development approach geared to speed, flexibility, and quality. Third, Kent Beck was an effective promoter. Fourth, Kent picked a great name—Extreme Programming—that targeted the developer audience and told the world there was something new, something “extreme” inside.

XP 由 Kent 开发，后来得到了 Ward Cunningham 和 Ron Jeffries 的协助，它提倡社区、简单、反馈、尊重和勇气的价值观。XP 的重要贡献在于它对变更成本的看法以及对技术卓越的重视。

XP, as developed by Kent with later assists from Ward Cunningham and Ron Jeffries, promotes the values of community, simplicity, feedback, respect, and courage. Important contributions of XP were its view of the cost of change and its emphasis on technical excellence.

尽管 Kent 并未声称结对编程和迭代规划等实践源自 XP，但这种方法确实包含了一些重要的新概念。Kent 对如何管理变革有一些想法，这也解释了他 2000 年出版的《极限编程解析》一书的副标题“拥抱变革”。XP 源自已存在很长时间的良好实践。正如 Kent 所说：“XP 中的想法都不是新的。大多数想法都和编程一样古老。”我可能在某一方面与 Kent 不同：虽然 XP 包含的实践并不新鲜，但明确的价值观和选择协同工作的实践却是新的。

Although Kent didn’t claim practices like pair programming and iterative planning originated with XP, this approach did include important new concepts. Kent had ideas about how to manage change—which explains the subtitle of his 2000 eXtreme Programming Explained book, Embrace Change. XP was derived from good practices that had been around for a long time. As Kent says, “None of the ideas in XP are new. Most are as old as programming.” I might differ with Kent in one respect: While the practices XP includes weren’t new, the explicit values and selecting practices that worked together were.

在早期，XP 为明确定义的问题领域（小型、同地团队）提供了特定的实践。Kent 将拥抱变化、协作团队、改变客户和开发人员之间经常出现问题的关系以及简单的生成规则等概念性思想融入到一套由一套明确原则指导的 12 项实践中。

In the early days, XP offered specific practices for a well-defined problem domain—small, co-located teams. Kent wrapped the conceptual ideas of embracing change, collaborative teamwork, altering the often-dysfunctional relationships between customers and developers, and simple, generative rules into a set of 12 practices guided by a set of well-articulated principles.

阿利斯泰尔·科克伯恩 (ALISTAIR COCKBURN) 创立了以人为本的 Crystal 系列方法。18^{阿利斯泰尔}是一位“方法考古学家”，他采访了全球数十个项目团队，试图将有效的方法与人们认为应该有效的方法区分开来。阿利斯泰尔专注于开发协作、良好公民意识和合作的人性方面。他使用项目规模、关键性和目标来为 Crystal 的每个成员配置实践方法论系列。软件开发是“发明和沟通的合作游戏”，Alistair 说。

ALISTAIR COCKBURN CREATED the Crystal family of people-centered methods.¹⁸ Alistair is a “methodology archaeologist” who interviewed dozens of project teams worldwide trying to separate what worked from what people said should work. Alistair focused on the people aspects of development collaboration, good citizenship, and cooperation. He used project size, criticality, and objectives to configure practices for each member of the Crystal family of methodologies. Software development is “a cooperative game of invention and communication,” says Alistair.

18.提醒：这是 Alistair 在 2002 年的作品。从那时起，他和其他敏捷主义者做出了更多贡献。

18. Reminder: This is Alistair’s work in 2002. He, and other agilists, have contributed much more since then.

Alistair 提出了一套“方法论”，团队可以从中选择一个起点，然后根据自己的需求进行调整。Crystal 这个名字指的是宝石的各个方面——每个方面都是底层核心的不同方面。底层核心代表价值观和原则，而每个方面代表一组特定的元素：技术、角色、工具和标准。Crystal 只有两条绝对规则：(1) 增量周期不能超过四个月，(2) 使用反思研讨会来确保方法论是自适应的。

Alistair proposed a “set” of methodologies from which teams could select a starting point and then tailor it to their needs. The name Crystal refers to the various facets of a gemstone—each a different face on an underlying core. The underlying core represents values and principles, while each facet represents a specific set of elements: techniques, roles, tools, and standards. There were only two absolute rules in Crystal: (1) Incremental cycles cannot exceed four months and (2) reflection workshops are used to ensure the methodology is self-adapting.

很多时候，关于实践的争论都具有俗话说的“苹果”与“橘子”的特点，因为一方谈论的是 500 人的航空航天项目，而另一方谈论的是 8 人的 Web 内容项目。Crystal 的领域定义有助于将讨论和方法集中在适当的问题领域上。

All too often, arguments over practices take on the proverbial “apples” versus “oranges” characteristics, because one side is talking about a 500-person aerospace project and the other side is talking about an 8-person web content project. Crystal’s domain definitions help focus discussions, and methodologies, on appropriate problem domains.

敏捷期

Agile periods

尽管敏捷时代跨越了 20 多年，但它包含几个不同的时期和时间框架，如图 5.6所示。Rogue Team 时期（2001-2004 年）始于敏捷宣言的发布，并在接下来的几年里随着敏捷运动的高速发展而延续。这场运动的发展速度比敏捷宣言作者预期的要快得多 - 尽管事实上我们真的不知道会发生什么。它的发展沿着两条轨道进行。第一条轨道专注于行业推广 - 撰写论文、在会议上发言、组织会议。第二条轨道是将这些想法付诸组织实践。在第一个时期，敏捷方法被各个团队压倒性地采用。他们想走在前列，但首先必须说服管理层让他们尝试。

While the Agile era spans more than 20-plus years, it encompasses several distinct periods and time frames, as shown in Figure 5.6. The Rogue Team period (2001–2004) began with the Agile Manifesto’s release and extended for the next few years as the agile movement kicked into high gear. The movement took off much faster than the Agile Manifesto authors had expected—although the truth is we didn’t really know what to expect. Its evolution moved along two tracks. The first was focused on industry promotion—writing papers, speaking at conferences, organizing conferences. The second was putting these ideas into practice in organizations. In this first period, agile methodologies were adopted overwhelmingly by individual teams. They wanted to be in the forefront but first had to convince their management to let them try it.

随后是“勇敢的管理者”时期（2005-2010 年），企业领导者对敏捷越来越感兴趣。相比之下，“流氓团队”时期则由下至上推动。曾在成功团队工作过的布道者（早年有很多布道者）试图说服高层管理人员进行企业转型——但大多以失败告终。

The Courageous Executive period (2005–2010) followed as enterprise leaders grew curious about the agile stuff. The Rogue Team period, by contrast, had been driven from the bottom up. Evangelists (there was plenty of evangelizing in the early years) who had worked on successful teams tried to convince upper management to make an enterprise switch—and mostly failed.

但是，尽管进展通常很慢，但关键影响者继续推动敏捷发展，然后倒退，然后再次前进。随着敏捷运动势头强劲、衡量成功的标准发生变化以及商业环境对性能的要求更高，敏捷主义者开始与希望其组织“敏捷化”的高层领导进行对话。他们通常并不真正理解自己在要求什么，也不切实际地了解实现转型需要什么，但他们还是继续前进。

But, while progress was often slow, the critical influencers continued to push forward, then back, then forward again. As the agile movement gathered momentum, as measures of success changed, and as the business environment demanded even more performance, agilists began to have conversations with senior leaders who wanted their organizations to “go agile.” They often didn’t really understand what they were asking for, nor were they realistic about what it would take to make the transition, but they forged ahead anyway.

勇敢的高管看到了价值主张，并开始考虑全面实施。例如，Salesforce 是最早全面采用敏捷开发的公司之一，它利用其加快交付速度和快速适应规模的能力，连续几年荣登《福布斯》杂志 100 强创新者榜单榜首。

Courageous executives saw the value proposition and began to think about comprehensive implementations. For example, Salesforce, one of the earliest companies to fully embrace agile development, used its ability to speed delivery and adapt to scale rapidly, winning the top spot in Forbes magazine’s top 100 innovators list several years in a row.

数字化转型时期（2011-2021 年）致力于解决企业层面的敏捷性问题。随着敏捷运动进入第二个十年，势头从勇敢的 IT 高管转移到企业高管——从 CIO 转移到 CEO。2010 年，IBM 采访了 1,500 多名 CEO，并在《利用复杂性》一书中发表了调查结果：

The Digital Transformation period (2011–2021) addressed agility at the enterprise level. As the agile movement entered its second decade, the momentum shifted from courageous IT executives to enterprise executives—from CIOs to CEOs. In 2010, IBM interviewed more than 1,500 CEOs and published its findings in Capitalizing on Complexity:

我们的采访显示，CEO 们现在面临着“复杂性差距”，这比我们在八年的 CEO 研究中衡量的任何因素都更具挑战性。八成 CEO 预计他们的环境变得更加复杂，不到一半的人相信他们知道如何成功应对。（IBM Corporation，2010 年）

Our interviews revealed that CEOs are now confronted with a “complexity gap” that poses a bigger challenge than any factor we’ve measured in eight years of CEO research. Eight in 10 CEOs expect their environment to grow significantly more complex, and fewer than half believe they know how to deal with it successfully. (IBM Corporation, 2010)

技术为组织创造了巨大的机遇，但利用这些机遇的同时也带来了巨大的挑战。

Technology was creating vast opportunities for organizations but capitalizing on them created vast challenges at the same time.

时代观察

Era observations

许多软件工程师在过去十年中一直致力于为软件开发带来结构和纪律，他们对新兴的敏捷运动感到担忧。他们认为敏捷开发是向过去临时做法的倒退。然而，任何观察过一支熟练的 XP 团队进行测试驱动开发、重构、结对编程和故事规划，同时使用白板、故事卡和挂图记录他们的工作的人，都能看出团队成员纪律严明，但工作方式有些不正式。敏捷（在这种情况下是 XP）将重点从文档转移到协作，取代了传统的形式。

Many software engineers, who had spent the previous decade bringing structure and discipline to software development, were concerned about the nascent agile movement. They viewed agile development as a retreat to ad hoc practices of the past. However, anyone watching a skilled XP team practicing test-driven development, refactoring, pair programming, and story planning, while documenting their work using whiteboards, story cards, and flip charts, could tell team members were highly disciplined, but worked somewhat informally. Agile (XP in this case) shifted the emphasis from documentation to collaboration, replacing traditional formality.

敏捷开发的另一个令人反感的问题是敏捷主义者的“极端”立场。批评者没有抓住要点。敏捷主义者正在测试将实践推向多远。XP 社区专注于关键技术实践，并将它们推向极限——极端——这对行业大有裨益。在一次会议上，我听到 Ron Jeffries 质疑极限：“如果敏捷开发说要减少文档，那如果我们什么都不做会怎么样？”这并不意味着 Ron 认为没有文档是普遍适用的（尽管我不确定），而是认为对于小型的、同地办公的团队来说没问题。对于较大的分布式团队或生命攸关的应用程序（如医疗起搏器），额外的形式化将是必要的。Ron 接着说：“如果提前一点规划比几个月的规划更好，那么持续增量规划怎么样？如果频繁测试是好的，那么测试优先怎么样？”通过突破极限，新的可能性被发现。

Another off-putting issue with agile development was agilists’ “extreme” positions. Detractors missed the point. Agilists were testing how far to push practices. The XP community focused on critical technical practices and pushed them to the limits—to the extreme—which did the industry a great service. At one conference I heard Ron Jeffries question limits: “If agile development says reduce documentation, what if we don’t do any?” That didn’t mean Ron thought no documentation was universally good (although I’m not sure about that), but rather that it was okay for a small, co-located team. Additional formalization would be necessary for larger, distributed teams or life-critical applications such as medical pacemakers. Ron went on: “If a little upfront planning is better than months of planning, what about continuous incremental planning? If frequent testing is good, what about test-first?” By pushing the limits, new possibilities were uncovered.

探索极限可以确定边缘情况。了解这些边缘情况让我们更好地了解可用的选项范围。在 XP 出现之前，人们在更狭窄的范围内思考什么是“可接受的（例如迭代长度）”。这种对边缘的探索在敏捷运动的早期阶段至关重要 - 我们必须采取极端立场才能引起人们的注意。如果 Kent Beck 开发了“适度编程”，会有人听吗？

Exploring the limits identified edge cases. Understanding those edge cases gave us a better understanding of the range of options available. Before XP came to the fore, people thought in much narrower ranges about what was “acceptable (iteration length, for example).” This exploration of the edges was critical in the early stages of the agile movement—we had to take extreme positions to get people’s attention. Would anyone have listened if Kent Beck had developed “moderate programming?”

批评者还忽略了敏捷的核心思维方式——学习和适应。从迭代结束时的团队反思到项目结束时的回顾，真正的敏捷主义者总是根据现实情况调整他们的实践，了解哪些方法有效，哪些方法无效。

Detractors also missed a core agile mindset—learning and adapting. From end-of-iteration team reflections to end-of-project retrospectives, true agilists are always adjusting their practices to the reality of what worked and what didn’t.

另一个误解是敏捷主义者没有发明任何新东西。生物学家 John Holland (1989) 在撰写有关复杂自适应系统理论的文章时说，创造力不仅来自一些新的科学理论，也来自以新方式将科学构件组合在一起的人——本质上是创造新事物。虽然每种敏捷方法都有早期的根源，但敏捷方法是 (1) 从技术、项目管理和协作实践领域“选定”的方法（新旧方法）；(2) 明确的基本价值观和原则思维模式；(3) 将这些想法整合到方法论中。Kent Beck 并没有“发明”12 种 XP 实践中的大多数，但他确实整合了 12 种互补、一致且有效的实践。他用特定的价值观为这些实践注入活力。虽然 XP 的每个部分可能不是 Kent 的创新，但这种组合肯定是。

Another misconception voiced was that agilists didn’t invent anything new. Biologist John Holland (1989), writing about complex adaptive system theory, says creativity comes not only from some new scientific theory, but also from people who put scientific building blocks together in a new way—in essence, creating something new. While there are early roots for every agile method, agile methodologies are a combination of (1) “selected” methods (old and new) from the realm of technical, project management, and collaboration practices; (2) a well-stated mindset of fundamental values and principles; and (3) an integration of these ideas into a methodology. Kent Beck didn’t “invent” most of the 12 XP practices, but he did assemble 12 that were complementary, consistent, and effective together. He energized these practices with specific values. While each individual piece of XP may not be Kent’s innovation, the combination certainly was.

最后，我想重复一下我在前言中写到的内容——将软件开发的演变与我的个人故事交织在一起，为我限制这本书的范围提供了基础。每位《敏捷宣言》的作者和其他人都有一系列与我相似的故事。因此，我对敏捷运动的历史显然是我的观点——幸运的是，这是一种视角，而不是偏见。也许《从狂野西部到敏捷》会激励其他人写出一部全面的敏捷或 Scrum 历史。

As a final observation, I want to repeat something I wrote about in the preface—that braiding the evolution of software development with my personal stories gave me a basis for limiting the scope of this book. Every Agile Manifesto author, and others, have a set of similar stories to mine. Thus, my history of the agile movement is distinctly my viewpoint—with luck, a lens rather than a bias. Maybe Wild West to Agile will inspire someone else to write a comprehensive agile or Scrum history.

刀具和游动

Cutter and travels

随着敏捷趋势的兴起，我与 Cutter Consortium 的合作也随之增多；这项工作贯穿了本章，还有几个客户故事。此外，本章还包含关键年份 2007 年的重要技术更新，以及与这个时代相关的敏捷项目管理主题。在 Rogue Teams 和 Courageous Executives 时代，我与客户合作并通过在会议上发言、撰写书籍和文章以及与敏捷联盟和敏捷领导力网络合作来推广、教育和提高人们对敏捷方法的认识，从而推广敏捷方法。我的大部分推广工作已在第 5 章中介绍过。本章简要介绍了我在 Cutter Consortium 的工作和我的各种旅行，之后重点介绍客户工作。

As the agile trend got under way, my work with the Cutter Consortium increased; it is woven throughout this chapter, as are several client stories. In addition, the chapter contains an important technology update for the pivotal year, 2007, and a look at agile project management topics relevant to this era. During both the Rogue Teams and Courageous Executives eras, I worked with clients and promoted agile approaches by speaking at conferences, writing books and articles, and working with the Agile Alliance and Agile Leadership Network to promote, educate, and raise awareness of agile methods. Most of my promotional work was covered earlier in Chapter 5. This chapter focuses on client work, after a brief foray into my work for the Cutter Consortium and my various travels.

在这一时期的早期，我成为了 Cutter Consortium 敏捷项目管理咨询和研究业务的主管。由于互联网继续对从杂志到书籍等各类印刷材料产生不利影响，我们停止了我之前撰写的电子商务研究报告，转而专注于客户工作和写书。在敏捷时代的早期，我的咨询工作既涉及软件公司，也涉及内部 IT 部门。

Early in this period I became the director of Cutter Consortium’s agile project management consulting and research practice. As the Internet continued to adversely impact printed materials of all types, from magazines to books, we discontinued the e-business research report I had been writing, and I focused on client work and writing books. My consulting work in these early Agile-era years was with both software companies and internal IT departments.

在卡特财团任职期间，我还是卡特商业技术委员会的一名研究员，当时委员会的成员包括汤姆·德马科、肯·奥尔、罗布·奥斯汀、凯伦·科伯恩、蒂姆·利斯特、卢·马祖切利、林恩·埃林、克里斯汀·戴维斯、彼得·奥法雷尔和埃德·尤顿。我们每年都会多次发表关于有新闻价值的 IT 话题的意见。我们采用了汤姆·德马科提出的流程，他是美国最高法院的学生。

During this time with the Cutter Consortium, I was also a fellow on the Cutter Business Technology Council, whose members at that time included Tom DeMarco, Ken Orr, Rob Austin, Karen Coburn, Tim Lister, Lou Mazzucchelli, Lynne Ellyn, Christine Davis, Peter O’Farrell, and Ed Yourdon. Several times a year, we published opinions on newsworthy IT topics. We used a process proposed by Tom DeMarco, who was a student of the U.S. Supreme Court.

卡特商业技术委员会采用美国最高法院的程序来识别重要的新趋势。虽然其他分析公司在预测时不解释他们如何得出结论，使整个过程看起来像是猜测，但该委员会措辞强硬的意见以及赞同和反对意见展示了预测背后的想法，包括并解释任何相反的观点^。3

The Cutter Business Technology Council approaches the identification of important new trends using a process adapted from the United States Supreme Court. While other analyst firms prognosticate without explaining how they reached their conclusions, making the whole process seem like guesswork, the Council’s strongly worded opinions and concurring and dissenting opinions display the thinking behind the predictions, including and explaining any contrary views.³

3. www.cutter.com​

3. www.cutter.com

讨论非常活跃，富有启发性。通过提出和呈现正反两方面的意见，这一过程为我们的对话增添了显著的深度。这是另一种合作模式。

Discussions were lively and enlightening. The process added remarkable depth to our conversations by having, and presenting, both pro and con opinions. It was yet another model for collaboration.

在敏捷时代的早期，我还在许多会议上发表过演讲，包括 2002 年在意大利撒丁岛举行的 XP 大会。有一次，Martin Fowler 偶然邀请我参加下一年会议的规划会议。我不知道他另有计划，结果我主持了 2003 年在意大利热那亚举行的 XP 大会。在敏捷时代的初期，我到处奔波，在会议上发表演讲，举办研讨会，并在印度、意大利、中国、丹麦、澳大利亚、德国、波兰和新西兰等遥远的地方提供咨询。

During the early years of the Agile era, I also spoke at a number of conferences, including the 2002 XP Conference in Sardinia, Italy. At some point, Martin Fowler casually invited me to a planning meeting for the next year’s conference. Not knowing he had a hidden agenda, I ended up chairing the 2003 XP Conference in Genova, Italy. In this first period of the Agile era, I traveled extensively speaking at conferences, conducting workshops, and consulting in far-flung locations including India, Italy, China, Denmark, Australia, Germany, Poland, and New Zealand.

在此期间，我与客户开展的活动范围广泛，从单一研讨会到长达一年的活动。本章后面的部分将单独介绍规模较大或值得关注的活动，但其中一些有趣的较短活动包括前往波兰和澳大利亚的旅行。

My client engagements during this period ran the gamut from single workshops to year-long engagements. The larger or noteworthy endeavors are described in their own sections later in this chapter, but a couple of the interesting shorter ones include trips to Poland and Australia.

2003 年，我在澳大利亚为富士通咨询公司举办了一场研讨会。该公司的高级咨询总监兼项目管理实践经理 Karen Chivers 在一封电子邮件中谈到了他们随后涉足敏捷开发的情况：“在过去的 12-18 个月中，富士通咨询公司已经看到了采用‘敏捷’方法交付和管理某些项目的潜在好处，并鼓励我们的客户接受‘适应性’项目文化。”

In 2003, I conducted a workshop in Australia for Fujitsu Consulting. Karen Chivers, the company’s senior consulting director and project management practice manager, had this to say in an email about their subsequent foray into agile development: “In the last 12–18 months, Fujitsu Consulting has seen the potential benefits of adopting ‘Agile’ approaches to the way we deliver and manage some of our projects and has encouraged our clients to embrace an ‘Adaptive’ project culture.”

政府机构通常对敏捷方法的研究进展缓慢，但澳大利亚社会保障服务机构 Centerlink 却并非如此。2003 年，我在其内部 IT 会议上发表了主题演讲，并与 Centerlink 的 CIO 和其他高级经理进行了富有成效的对话。

Government organizations were generally slow to investigate agile methods—but not Centerlink, the Australian social security service organization. In 2003, I gave the keynote address at its internal IT conference and had fruitful conversations with Centerlink’s CIO and other senior managers.

2004 年，IT 咨询公司 InfoVide 的总裁 Borys Stokalski 邀请我去波兰，在公司的年度聚会上发表演讲，然后教授敏捷项目管理研讨会。在华沙举办的三天研讨会结束后，Borys 开始向其客户提供自适应/敏捷方法。

Borys Stokalski, president of InfoVide, an IT consulting firm, invited me to Poland in 2004 to give a talk at his company’s annual get-together, then teach an Agile Project Management workshop. After this three-day workshop in Warsaw, Borys began offering adaptive/agile methods to their clients.

21 世纪初，我在印度举办研讨会时，曾在孟买举行的印度计算机协会会议上发表演讲。当时，印度公司宣称能力成熟度模型 (CMM) 是他们的竞争优势。演讲结束后，有个人发言：“您的方法实际上就是我们的工作方式；我们只是不愿承认而已。”这是一次旋风之旅，我在钦奈、海得拉巴和孟买举办了敏捷项目管理研讨会。印度软件组织仍处于 CMM 的阵痛之中，但似乎愿意考虑敏捷方法。

While teaching workshops in India in the early 2000s, I spoke at a meeting of the Computer Society of India in Mumbai. At that time, Indian companies were touting the Capability Maturity Model (CMM) as their competitive advantage. After my presentation, one individual spoke up: “Your approach is actually how we work; we just can’t admit it.” This was a whirlwind trip teaching Agile Project Management workshops in Chennai, Hyderabad, and Mumbai. Indian software organizations were still in the throes of the CMM, but seemed open to thinking about agile methods.

刚刚描述的澳大利亚、波兰和印度之行代表了我在 Rogue Teams 期间的典型经历。企业对敏捷方法既好奇又犹豫。然而，除了较小的公司外，很少有人考虑在企业范围内实施。采用敏捷方法的动力来自开发人员，而纪念碑式方法论则被管理层吹捧为最佳实践。回想起来，结构化方法首先遵循了实践者兴奋的道路，然后是管理层的参与。敏捷开发可能会走上同样的道路，将其变成纪念碑式敏捷开发 (MAD)。

The Australia, Poland, and India travels just described represent typical engagements of mine during the Rogue Teams period. Enterprises were both curious and hesitant about agile approaches. Nevertheless, except for smaller firms, few were thinking about enterprise-wide implementations. The impetus for adopting agile methods came from developers, whereas Monumental Methodologies had been touted as best practices by management. Thinking back, structured methods followed a path of practitioner excitement first, management involvement later. There is a danger that agile development will follow the same path, turning it into Monumental Agile Development (MAD).

2005 年，我获得了国际史蒂文斯奖，这是再造论坛颁发的软件工程演讲奖，旨在表彰对软件和系统开发方法文献或实践的杰出贡献。该奖项从 1995 年颁发到 2005 年，获奖者包括 Larry Constantine、Grady Booch、Gerald Weinberg 和 Tom DeMarco。这再次表明敏捷运动正在得到更广泛的软件工程和开发社区的认可。

In 2005, I received the International Stevens Award, a software engineering lecture award given by the Reengineering Forum to recognize outstanding contributions to the literature or practice of methods for software and systems development. The award was given out from 1995 until 2005, and included contributors Larry Constantine, Grady Booch, Gerald Weinberg, and Tom DeMarco. It was another indication that the agile movement was being recognized in the wider software engineering and development communities.

我的故事传达了人们对敏捷开发日益增长的兴趣的例子。但所有《敏捷宣言》的合著者以及其他许多人都有类似的故事。Scrum 通过其认证课程和 Scrum Alliance 的成立，将敏捷运动的影响力扩大到了任何其他敏捷方法都无法企及的程度。虽然 XP 在市场份额上处于领先地位，但 Scrum 很快就吸走了市场上剩余的氧气。认证是否真正有效是备受争议的话题。认证能赚钱这一点毋庸置疑——它确实能赚钱。

My stories convey examples of the expanding interest in agile development. But all of the Agile Manifesto co-authors, and many others, have similar stories. Scrum, through its certification courses and the formation of the Scrum Alliance, extended the agile movement’s reach further than any other agile approach did. While XP had the early lead in market share, Scrum quickly sucked up the rest of the oxygen in the market. Whether certification was truly effective was the subject of much debate. That certification made money was not debatable—it did.

作为 Cutter Consortium 敏捷项目管理小组的顾问和主管，我花了大量时间与来自各种行业、公司规模、国家和敏捷阶段。以下将探讨各种敏捷实施、挑战和成功案例。

As a consultant and director of the Cutter Consortium’s Agile Project Management group, I spent considerable time with clients from a wide variety of industries, company sizes, countries, and stages of agility. The following engagements are explored here to illustrate a variety of agile implementations, challenges, and successes.

Cellular, Inc. 的 Mustang 团队⁴

The Mustang Team at Cellular, Inc.⁴

4.本故事是 Highsmith (2002) 中所讲述故事的简化版。

4. This story is a briefer version of that presented in Highsmith (2002).

Jeremy 和他在位于不列颠哥伦比亚省温哥华的 Cellular, Inc. 的产品团队是高度不确定的商业环境中工作所带来的头痛、心痛和紧张的典型代表。产品团队（代号为“野马”）在弥补竞争劣势的过程中面临着重大的业务、组织和技术障碍。该项目的目标是为下一代蜂窝电话芯片提供软件。1999 年末，他们发现外部软件承包商远远没有达到预期，因此管理层决定将产品开发带回公司。由于已经开发了近 300,000 行嵌入式 C 代码，他们的首要任务是弄清楚供应商到底完成了什么。

Jeremy and his product team at Cellular, Inc., in Vancouver, British Columbia, epitomize the headaches, heartaches, and tensions of working in highly uncertain business environments. The product team—code-named “Mustang”—faced major business, organizational, and technical hurdles in its quest to make up a competitive deficit. The project’s goal was to deliver software for next-generation cellular telephone chips. In late 1999, it became apparent that their outside software contractor was far from meeting expectations, so management decided to bring the product development back into the company. With nearly 300,000 lines of embedded C code already developed, their first job was to figure out just what the vendor had accomplished.

回国后，团队意识到代码的状况有多糟糕——30 万行代码中的需求实现得很糟糕。有趣的是，设计文档还算合理，但从设计到代码的转换却很糟糕，而且漏洞百出。团队的首要任务是通过开发足够的测试环境来稳定代码。随着测试的进行，团队不断发现本来应该实现的指定功能并没有实现。

Once repatriated, the team realized what truly foul shape the code was in—300,000 lines of code in which the requirements were poorly implemented. Interestingly, the design documents were reasonable, but the translation from design to code was atrocious and very buggy. The team’s first job was to stabilize the code by developing an adequate testing environment. As testing proceeded, the team was constantly finding specified features, which had supposedly been implemented, were just not there.

产品需求处于不断变化的状态。团队的最初目标是提供符合联盟标准的软件。这些大客户（主要的手机供应商）已经建立了一个互操作性实验室，供应商将他们的产品提交给该实验室进行认证。不幸的是，联盟的“需求文档”留下了许多问题，而 Cellular 的产品营销团队似乎不愿意（或者说无法（我只听到了一面之词））帮助澄清需求中的模糊之处。有时潜在客户的需求实际上是“让它做这部手机能做的事情”。当团队最终将产品提交给互操作性实验室时，那里的工作人员非常愿意回答问题，最终团队实现了其互操作性目标。

Product requirements were in a constant state of flux. The team’s initial goal was to deliver software that met a consortium’s set of standards. These large customers (major cellular phone suppliers) had established an interoperability lab to which suppliers submitted their products for certification. Unfortunately, the consortium’s “requirements document” left many questions, and Cellular’s product marketing group seemed unwilling—or unable (I heard only one side of the story)—to help clear up requirements ambiguities. Sometimes the requirements from prospects were virtually “make it do what this phone does.” When the team finally submitted its product to the interoperability lab, the staff there were very willing to answer questions and eventually the team met its interoperability goal.

在这次合作中，我举办了一场自适应软件开发 (ASD) 研讨会，并咨询了开发人员和经理。我采访了三位关键人物：Jeremy 是开发经理，Luke 是软件流程经理，John 是关键开发人员。他们的观点有相似之处，当然也有一些不同之处。三人都认为该项目是成功的——至少从实现互操作性目标的角度来看是这样。然而，Luke 并不完全相信这个目标应该被视为真正的成功，因为实际的产品发布还有几个月的时间。

During this engagement, I conducted an Adaptive Software Development (ASD) workshop and consulted with the development staff and managers. I interviewed three key people: Jeremy was the development manager, Luke was the software process manager, and John was a key developer. Their perspectives had similarities and, naturally, some differences. Each of the three considered the project to be a success—at least from the perspective of meeting the interoperability goal. Luke, however, was not entirely convinced that this goal should be considered a true success, considering the actual product release was still several months away.

不断变化的需求让团队感到沮丧，因此他们想出了一个解决方案——冻结需求。虽然这个解决方案可能会缓解挫败感，但这意味着他们的客户不会满意。在一个动荡的行业中，他们需要想出适应市场需求的方法。

Constantly changing requirements frustrated the teams to the point they came up with a solution—freeze the requirements. While that solution might have eased frustration, it meant their customers wouldn’t be happy. In a volatile industry, they needed to figure out ways to adapt to the market needs.

该团队采用了迭代规划和时间限制发布流程。我帮助他们使用 ASD 组件调整了流程。他们按季度到年底规划目标。这些季度目标包含主要功能，但团队成员对功能有一定的自由度。他们将这个过程称为“具有伸缩粒度的滚动规划窗口”。因此，他们总是有一个以一周为粒度的一个月计划、一个以一个月为粒度的三个月计划和一个以一个季度为粒度的一年计划。他们将这种方法称为时间限制，因为发布日期都是固定的，唯一的变量是分配给每个版本的功能。

The team employed iterative planning and time-boxed release processes. I helped them tweak their process with components of ASD. They planned goals by quarter through year’s end. These quarterly goals contained major functionality, but the team members had some latitude with features. They called this process “scrolling planning window with telescoping granularity.” Thus, they always had a one-month plan with one-week granularity, a three-month plan with one-month granularity, and a one-year plan with one-quarter granularity. They referred to this methodology as time-boxing, because the release dates were all fixed and the only variable was the features assigned to each release.

包括约翰在内的几位团队成员对这种“自适应”规划（杰里米称之为）感到不舒服。约翰觉得为每月发布做准备浪费了太多时间。此外，有时他和卢克都认为短迭代的时间压力迫使团队过于专注于完成功能，而不是努力提供更好的质量。尽管团队成员试图做一些重新设计（重构）工作，但他们与从头开始的团队处于不同的境地——他们不断与现有的实时代码作斗争，甚至他们昂贵的测试设备也包含难以控制的错误。

Several team members, including John, were uncomfortable with this “adaptive” planning, as Jeremy referred to it. John felt that too much time was wasted getting ready for the monthly releases. Also, at times both he and Luke thought the time pressures of the short iterations forced the team into concentrating too much on getting features done rather than on trying to deliver better quality. Although the team members attempted to do some redesign (refactoring) work, they were in a different position than a team starting with a clean slate—they were constantly battling with the existing real-time code, and even their expensive testing equipment contained unruly bugs.

“您的自适应软件开发研讨会帮助降低了团队的焦虑水平，”Jeremy 说，“通过让每个人都从局外人的角度看，这种类型的项目的动荡和紧张是正常的。”我还听到了几位主管和团队领导的发言。当人们不知道处于混乱边缘的生活的常态时（有时即使他们知道），他们往往会做出负面反应。不幸的是，一些团队领导夸大了这个问题。当团队成员哀叹“一切都搞砸了，而且每天都在恶化”时，一些领导会回答“确实如此”（或类似的话），这只会加剧个人的焦虑。

“Your Adaptive Software Development workshop helped reduce the level of anxiety in the group,” Jeremy said, “by giving everyone an outsider’s view that the turbulence and tension on this type of project are normal.” I also heard from several supervisors and team leads. When people are unaware of the normalcy of life at the edge of chaos (and even sometimes when they are), they tend to react negatively. Unfortunately, some of the team leaders magnified the problem. To a team member’s lament that “Everything is screwed up and getting worse daily,” some of the leads would respond, “It sure is” (or words to that effect), which only amplified individuals’ anxiety.

领导者的职责之一是吸收不确定性和模糊性，而不是将其反射回去，从而使情况恶化。只要有人承认事情有些混乱，这种情况很正常，他们意识到会出现一些效率低下的情况，就可以帮助缓解紧张局势。最糟糕的方法是试图否认焦虑，比如“你不应该焦虑”。敏捷意味着对需要重新制定和重新审视优先事项的变化做出反应。流程和态度都有助于缓解紧张局势。

One of the jobs of people in leadership positions is to absorb uncertainty and ambiguity, not reflect it back and thereby worsen the situation. Just having someone admit things are somewhat chaotic, that situation is normal, and they realize some inefficiencies will occur can help relieve tension. The worst approach is attempting to deny the anxiety, as in “You shouldn’t be anxious.” Being agile means responding to changes requiring rework and revisiting priorities. Both process and attitude can contribute to easing the tension.

Mustang 团队的经历是这一时期的典型：由于产品开发具有高变化、高风险的性质，他们尝试了一种敏捷开发形式。该团队担心他们的传统方法是否适用于这项工作，因此他们说服管理层允许他们在这项工作中采用非传统方法。但同样，他们的成功方法并没有在更广泛的组织中流行起来。

The experience of the Mustang team was typical of this period: They were attempting a form of agile development because of the high-change, high-risk nature of their product development. The team had concerns about their traditional methodology working for this effort, so they convinced management to allow them to go rogue for this effort. But again, their successful approach didn’t catch on within the wider organization.

科技（1995–2007）

Technology (1995–2007)

这一技术年表与本书其他部分所列举的时代不同，因为有两个关键的转折点。第一个转折点是互联网的快速崛起，始于 20 世纪 90 年代初，并在 90 年代后期和 21 世纪初加速发展。第二个转折点涉及 2007 年出现的巨大技术创新。

This technology chronology differs from that of the eras identified elsewhere in this book because of two key inflection points. The first was the rapid rise of the Internet, which began in the early 1990s and accelerated in the latter part of the decade and into the early 2000s. The second involved the tremendous technology innovations that arose in 2007.

2007 年是一个重大的转折点，导致经济和特定企业都陷入动荡。三届普利策奖得主、畅销书作家和《纽约时报》专栏作家托马斯·弗里德曼在其著作《谢谢你的迟到》 （2016 年）中，将 2007 年称为多种技术结出硕果并推动数字化加速发展的一年。苹果推出了 iPhone，Hadoop 开启了大数据时代，GitHub 使软件开发能力倍增，Facebook 和 Twitter 扩大了社交媒体的覆盖面和影响力，Airbnb 展示了小公司可以利用这些新技术做些什么，Kindle 改变了图书阅读和出版业务，谷歌推出了适用于智能手机的 Android 操作系统。所有这些技术的融合催生了新的平台公司，例如 Airbnb，其管理的床位数量超过了所有大型连锁酒店的总和。因此，2007 年加速了企业向数字化的进军，并对软件开发人员提出了新的要求。

The year 2007 was an epic inflection point, causing turmoil in both the economy and specific enterprises. In his book Thank You for Being Late (2016), Thomas Friedman, a three-time Pulitzer Prize winner, bestselling author, and columnist for The New York Times, anointed 2007 as the year when multiple technologies came to fruition and kicked digital acceleration into high gear. Apple introduced the iPhone, Hadoop ushered in the Big Data era, GitHub multiplied software development capabilities, Facebook and Twitter expanded the reach and influence of social media, Airbnb showed what small companies could do with these new technologies, the Kindle changed book reading and the publishing business, and Google launched the Android operating system for smartphones. The confluence of all these technologies enabled new platform companies, such as Airbnb, which managed more beds than all of the major hotel chains combined. Thus, 2007 accelerated the march toward digital enterprises and placed new demands on software developers.

发生了两次重大的架构转变：从早期的大型机架构到客户端-服务器架构，最后到互联网架构。当然，这些架构变化在各个组织之间有很大的重叠。每次转变都有四个基本问题的答案：

Two major architectural pivots occurred: from mainframe architectures early in the period to client-server architectures, and then to Internet architecture at the end. Of course, these architectural changes overlapped considerably from organization to organization. The answers to four basic questions characterize each transition:

• 物理计算机系统组件（计算机、数据库、用户界面设备）是本地的还是远程的？

• Were the physical computer system components (computer, database, user-interface devices) local or remote?

• 应用程序数据是存储在本地还是远程？

• Was application data stored locally or remotely?

• 计算逻辑是本地的还是远程的？

• Was computational logic local or remote?

• 表示层逻辑是本地的还是远程的？

• Was presentation layer logic local or remote?

我们把这称为“分配到层”问题。在大型机时期，所有三个层都是本地的。计算机归企业所有。数据存储设备归企业所有并位于计算机中心。计算和表示逻辑是本地的。“哑终端”包含很少的逻辑能力，使用以太网协议通过物理线路连接到计算机。

Let’s label this the “allocation-to-layer” issue. During the mainframe period, all three layers were local. Computers were owned by the enterprise. Data storage devices were owned and located in a computer center. Computational and presentation logic was local. “Dumb terminals,” containing little logic capability, were attached to the computer by physical wires, using an Ethernet protocol.

随后，一切都开始发生变化：从大型机时代，一切都在本地；到客户端-服务器时代，数据、逻辑和设备的分布向外迁移；再到互联网时代，网络吸收了一切。客户端-服务器架构需要决定逻辑和数据将驻留在何处——在大型机、客户端终端还是网络服务器上。有些将计算层分为几个部分——业务逻辑层和表示层逻辑。客户端通常包含表示层，可能还有一些本地数据。这些分配可能会变得非常混乱。公司，尤其是软件公司，一直在努力解决这个层分配问题，并花费大量资金来适应这些变化。

Then, it all began to change: from the mainframe period, when everything was local; to the client-server period, when the distribution of data and logic and devices migrated outward; to the Internet period, when the network absorbed everything. Client-server architecture required decisions about where logic and data would reside—on a mainframe or client terminals or network servers. Some broke the computational layer into several parts—business logic layer and presentation layer logic. The client side often contained the presentation layer and maybe some local data. These allocations could become very messy. Companies, especially software companies, struggled with this allocation-to-layer issue and spent large amounts of money adjusting to the changes.

随后，两项技术进步再次改变了分配到层的问题——互联网和云计算。云计算实现了通过互联网按需使用数据存储和计算机处理。大型计算机让位于庞大的服务器群，但许多公司仍保留了自己的服务器。云计算使公司能够将其拥有的服务器群外包给 Google 或 Microsoft 等服务提供商。云方法的优势包括轻松、平稳和快速扩展，以及可变（而不是大而固定）的成本增加。缺点是失去控制、数据安全性和潜在的停机性能。

Two technological advances then altered the allocation-to-layer issue once again—the Internet and cloud computing. Cloud computing enabled on-demand use of data storage and computer processing over the Internet. Mainframe computers gave way to vast server farms, but many companies retained their own servers. Cloud computing enabled companies to outsource their owned farms to a services provider like Google or Microsoft. Advantages of the cloud approach included easy, smooth, and rapid scaling, as well as variable (rather than large, fixed) cost increases. Disadvantages were loss of control, data security, and potential downtime performance.

云计算鼓励了微服务等新的软件开发实践。微服务和领域驱动设计始于 2004 年左右，是一种分解单片软件架构的方法。云计算促进了微服务的开发和管理。在“无服务器架构”（云计算的产物）时代，开发人员不再负责容量规划、配置、容错或扩展。企业再次面临艰难的选择，包括将应用程序转换为云服务是否值得。在此期间，最终用户设备往往是个人电脑——尽管这种情况很快就会改变。

Cloud computing encouraged new software development practices such as microservices. Microservices and domain-driven design began around 2004 as a way to decompose monolithic software architectures. Cloud computing facilitated microservices development and management. In the era of “serverless architectures” (an outgrowth of cloud computing), developers were no longer responsible for capacity planning, configuration, fault tolerance, or scaling. Enterprises once again faced difficult choices, including whether it was worth the cost to convert applications to cloud services. During this period, end-user devices tended to be personal computers—though that would soon change.

如前几章所述，人机界面技术已从穿孔卡片发展到各种各样的个人电子设备。如今，这种发展势头仍在继续：

As described in earlier chapters, the technology of person–computer interfaces had evolved from punch cards to the wide variety of personal electronic devices. Today, this evolution continues unabated:

界面在手势、语音和触摸方面不断发展，调动着所有感官。日常生活中与我们合作的设备很常见，软件和硬件的搭配也更加丰富。设备本身也变得更加符合人体工程学，旨在以最小的干扰融入日常互动。我们现在看到更多的智能设备，本地和基于云的 AI [人工智能] 解决方案支持日常决策。

Interfaces continue to evolve across gesture, voice, and touch—engaging all the senses. Devices that work with us in our everyday lives are commonplace and a richer pairing of software and hardware. Devices themselves are becoming more ergonomic, designed to slot into everyday interactions with minimal disruption. We now see more intelligent devices, with local and cloud-based AI [artificial intelligence] solutions supporting day to day decision-making.

自动驾驶并不是互动不断发展的唯一例子，但却为这种视角的实际应用提供了有力的例子。我们已迅速从基于交通的实时地图服务转向自动驾驶汽车，这些汽车不断模拟道路上车辆未来可能采取的所有行动，以实现更低的风险结果。（Thoughtworks.com，nd）

Autonomous driving is not the only example of evolving interactions but provides powerful examples of this lens in action. We’ve moved very quickly from real-time, traffic-based mapping services to self-driving cars that are constantly simulating all the possible future actions of the vehicles on the road to realize lower risk outcomes. (Thoughtworks.com, n.d.)

随着互联网和云计算改变了格局，软件即服务 (SaaS) 成为首选架构，尤其是对于软件公司而言。还记得真正的旧时代（20 世纪 90 年代初），当时程序是通过 3¼ 英寸磁盘加载的，而软盘已不再是软盘。后来出现了光盘 (CD) 上的程序，速度更快，磁盘更少。如今，几乎所有程序都是从互联网上下载的。SaaS 模式还利用互联网和云的功能，在客户端系统上以最少的逻辑提供应用服务。这样可以快速访问新功能，而无需大量安装成本。

As the Internet and cloud computing altered the landscape, Software as a Service (SaaS) became the architecture of choice, especially for software companies. Remember the real old days (the early 1990s), when programs were loaded via 3¼-inch diskettes that were no longer floppy? Then came programs on compact disks (CDs), much faster and with fewer disks. Today, nearly all programs are downloaded off the Internet. SaaS model also uses the capabilities of the Internet and cloud to provide application services with minimum logic on the client systems. This provides quick access to new features without major installation costs.

SaaS 方法完成了从大型机上应用程序与终端连接（20 世纪 90 年代初期之前组织中的 IT 模型）到 21 世纪中期完全基于互联网的应用程序的转变。客户端-服务器系统，其中业务应用程序逻辑被拆分为客户端和服务器对许多人来说是一项过渡技术，但也是现代化的并且仍然有用。

The SaaS approach completed the transition from applications on a mainframe with attached terminals (the model for IT in organizations until the early 1990s) to fully Internet-based applications by the mid-2000s. Client-server systems, in which business application logic was split between the client and the server, were a transitional technology for many, but were also modernized and still useful.

无论从技术角度还是管理角度来看，这些转变都不是小事。技术转型成本高昂，因为它涉及大约 10 年内两次重大的架构转变。IT 经理从向客人展示庞大的大型计算机中心到向他们展示笔记本电脑。现在，甚至硬件都是无形的 - 它位于某个“云端”！起初，反对 SaaS 的理由包括数据安全、服务停机时间和控制。然而，很快，“即服务”架构概念就广泛传播到基础设施即服务 (IaaS)、平台即服务 (PaaS) 和一切即服务 (EaaS) 等领域。

These transitions were not trivial, from either a technological or a managerial perspective. The technology transition was expensive because it involved two major architectural shifts within a span of about 10 years. IT managers went from showing guests their massive mainframe computer center to showing them a laptop computer. Now, even the hardware was intangible—it was in the “clouds” somewhere! At first, objections to SaaS included safety of data, service downtime, and control. All too soon, though, the “as a service” architecture concept spread widely to areas such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Everything as a Service (EaaS).

2000 年代中期的另一项重大技术进步是大数据——它确实非常庞大。1999 年，1 千兆字节 (GB) 的数据被认为是“大”。我记得有一段时间，1 太字节 (TB；1 TB = 1,024 GB) 似乎遥不可及；到 2022 年，您可以花 62 美元从亚马逊购买 2 TB 的存储空间。2022 年，大数据以拍字节 (PB；1 PB = 1,024 TB) 或艾字节 (EB；1 EB = 1,024 PB) 为单位。据报道，eBay 拥有两个容量分别为 7.5 PB 和 40 PB 的数据仓库，以及另一个 40 PB 的 Hadoop 集群。还记得 PC 使用软盘的时候吗？存储 1 TB 的数据需要 728,177 张软盘。 1970 年，一个全新的 IBM 2314 磁盘驱动器（存储容量为 146 MB（0.15 GB））的价格为 175,000 美元。按照这个价格计算，1970 年 1 GB 的 2314 存储容量的价格为 120 万美元，1990 年为 1 万美元，2012 年为 0.10 美元。5^这些成本的大幅下降是大数据发展的重要推动因素，引入 Hadoop 来管理这些海量数据库也是一大推动因素。

THE OTHER MAJOR TECHNICAL advance in the mid-2000s was Big Data—and it was, indeed, huge. In 1999, 1 gigabyte (GB) of data was considered “big.” I remember a time when 1 terabyte (TB; 1 TB = 1,024 GB) seemed far, far off; in 2022, you could purchase 2 TB of storage from Amazon for $62. In 2022, Big Data was measured in petabytes (PB; 1 PB = 1,024 TB) or exabytes (EB; 1 EB = 1,024 PB). eBay is reported to have two data warehouses with capacities of 7.5 PB and 40 PB, and another Hadoop cluster of 40 PB. Remember when PCs used floppy disks? It would take 728,177 floppy disks to store 1 TB of data. In 1970, a brand-new IBM 2314 disk drive with 146 MB (0.15 GB) of storage cost $175,000. At that rate, 1 GB of 2314 storage would cost $1.2 million in 1970, $10,000 in 1990, and $0.10 in 2012.⁵ These plunging costs were a significant enabler for Big Data’s evolution, as was the introduction of Hadoop to manage these massive databases.

5.很多网站都提供这些数字的版本。选择一个。

5. Any number of sites provide their version of these numbers. Pick one.

这些巨大的数字听起来就像宇宙学家谈论星系或宇宙中的恒星数量。但大数据带来了大问题。数据科学家等专业角色的出现增加了复杂性和成本，数据网格等新术语蓬勃发展，软件开发人员和数据库设计师之间数十年的分歧需要解决。我第一次经历这种分歧是在 20 世纪 80 年代我在芝加哥证券交易所工作时（第 3 章中描述），20 世纪 90 年代在耐克工作时再次经历这种分歧（第 4 章中描述）。它持续了很长时间。

These huge numbers sound like cosmologists talking about the number of stars in a galaxy or the universe. But with Big Data came big problems. Specialty roles like data scientist were created that added complexity and cost, new terms like data mesh flourished, and the decades-old schism between software developers and database designers needed fixing. I first experienced this schism with my Chicago Stock Exchange work in the 1980s (described in Chapter 3), and again in the 1990s at Nike (described in Chapter 4). It had persisted for a long time.

Ken Collier 是 Thoughtworks 北美数据和人工智能技术总监，也是《敏捷分析：商业智能和数据仓库的价值驱动方法》（Collier，2012 年）一书的作者。2002年，我搬到亚利桑那州弗拉格斯塔夫时，一位共同的朋友介绍了我和他。当我们都在城里时，我们经常见面喝咖啡聊天。我和 Ken 一起在 Cutter Consortium 项目上工作，后来又在 Thoughtworks 工作。

Ken Collier is the technical director of data and AI for North America for Thoughtworks and author of Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing (Collier, 2012). He and I were introduced by a mutual friend when I moved to Flagstaff, Arizona, in 2002. When we both were in town, we met for coffee and conversation on a regular basis. I worked with Ken on Cutter Consortium projects and later at Thoughtworks.

肯和我都是业余探险家——攀岩、徒步旅行、漂流、骑自行车——尽管我在这些活动上比肯更业余。我和他最难忘的一次出游始于亚利桑那州卡梅伦的纳瓦霍保留地，我们骑车去了大峡谷国家公园东入口内的沙漠观景瞭望塔。经过这段 62 英里、海拔 4,100 英尺的骑行后，我们筋疲力尽。在上山的路上，我们遇到了一位日本自行车旅行者，他已经在路上骑行了三个月，骑车游遍了美国西部。他是我们那天见到的唯一另一个骑自行车的人。

Ken and I are both amateur adventurers—climbing, hiking, river running, biking—although I was more amateurish at these activities than Ken. My most memorable outing with him started in Cameron, Arizona, on the Navajo Reservation, cycling to the Desert View Watchtower just inside the east entrance of the Grand Canyon National Park. We were pooped after this 62-mile, 4,100-foot-elevation-gain ride. On the way up, we met a Japanese bike tourer who had been on the road for three months, biking all over the western United States. He was the only other cyclist we saw that day.

我想谈谈您对数据和开发组织之间长期以来存在的分歧的感受。我记得在 20 世纪 80 年代中期与数据人员发生过争论。您对这种分歧有何看法？您、斯科特·安布勒和其他人是如何努力弥合这种分歧的？

What I wanted to talk about is your experience of the schism between data and the development organizations going back a long way. I remember having arguments with data people in the mid-1980s. What are your thoughts about the schism and how did you, Scott Ambler, and others try to bridge that gap?

这在一定程度上与数据库的发展有关，尤其是 90 年代的数据仓库。在 70 年代和 80 年代分层数据库的早期，软件开发人员编写代码。当时的数据工具很少。后来出现了关系数据库管理系统，例如 IBM 的 DB2，然后是 Oracle。在早期，数据库支持财务、供应链管理和其他运营应用程序。

Part of this has to do with how databases evolved and especially data warehousing in the nineties. In the early days of hierarchical databases in the seventies and eighties, software developers wrote code. There were few data tools. Then relational database management systems emerged such as IBM’s DB2, then Oracle. In the early days, databases supported finance, supply chain management, and other operational applications.

20 世纪 90 年代，商业智能 (BI) 和数据仓库系统提供了管理信息。此后不久，供应商创建了减少或消除编程需求的工具。人们成为数据从业者，而不是软件工程师。商界人士开始将简历重点放在工具上 — — 例如，很少编写代码的 Informatica 提取-转换-加载 (ETL) 开发人员。SQL 程序员、数据建模者和数据库管理员等各种角色创建了额外的 IT 功能孤岛。

In the nineties, business intelligence (BI) and data warehousing systems delivered management information. Quickly thereafter, vendors created tools that reduced or eliminated the need for programming. People became data practitioners instead of software engineers. Businesspeople started focusing their resumes on tools—for example, an Informatica extract-transform-load (ETL) developer who rarely wrote code. Various roles, such as SQL programmers, data modelers, and database administrators, created additional IT functional silos.

正是在那时，分裂发生了。我看到一些从计算机科学专业毕业的人成为了软件工程师，而另一些人则学校里的 CIS [计算机信息系统] 课程的学生没有编写代码，也没有编写测试计划或测试的任何概念。

That’s when the schism occurred. I saw people coming out of computer science programs who were software engineers, and out of CIS [computer information systems] programs in schools who didn’t write code or have any concepts of writing test plans or tests.

2000 年代初我遇到你时，我手头有一个项目进展不顺。需求收集花了一年时间；然后他们聘请我担任技术主管，负责实施项目。考虑到需求，他们固定的时间表是不现实的。当我和你一起做敏捷支持项目时，我与数据团队合作讨论测试自动化、构建自动化和创建测试框架。每当我展示一行 Java 代码来围绕他们正在使用的任何工具添加一些测试时，全班都会大吵大闹——“没有代码，没有代码。”

When I met you in the early 2000s, I had a project that was going badly. The requirements took a year to collect; then they hired me as the tech lead to run the implementation project. Given the requirements, their fixed schedule was unrealistic. When I was doing agile enablement projects with you, I worked with data teams talking about test automation, build automation, and creating testing frameworks. The minute I would show a line of Java code for adding some tests around whatever tool they were working with, the class would riot—“No code, no code.”

在此期间，我和斯科特·安布勒 (Scott Ambler) 和其他几个人试图让数据从业者思考敏捷方法，但他们认为这些方法不适合复杂的数据管理和分析。

During this period, Scott Ambler, a few others, and I tried to get the data practitioners to think about agile methods, but they considered them unsuitable for the complexities of data management and analytics.

2006 年，一套用于处理海量数据的技术 Hadoop 出现后，情况再次发生变化。管理海量数据集的复杂性再次要求编写代码。这开始了数据工程师和软件工程师的重新融合。

The situation changed again when Hadoop, a set of technologies for handling massive amounts of data, emerged in 2006. The complexities of managing massive data sets required writing code again. This began a reconvergence of data engineers and software engineers.

20 世纪 90 年代，人们以成为某一特定工具的专家为职业目标。如今，数据工程师是软件工程师，他们还具备“如何扩展？如何处理海量数据？管理数据和评估数据质量的最佳实践是什么？”等额外知识。

In the 1990s, people built careers around being a specialist in a particular tool. Now data engineers are software engineers with additional knowledge about “How do we scale? How do we deal with volume? What are best practices for managing your data and evaluating the data quality?”

公司在云端是否拥有更多的架构选择？

Do firms have more architectural choices in the cloud?

他们确实在这么做。但我开始看到的是 20 世纪 90 年代的重演。三大云供应商（谷歌、亚马逊和微软）都在提供一系列托管服务，这些服务实际上是他们试图让客户采用的商业工具。如果你是微软 Azure 客户，并且购买了 Azure 上的工具集合，他们就会把你锁定，因为如果你的所有代码都在专有工具中，那么很难从 Azure 迁移到 AWS [亚马逊网络服务]。

They do. But what I’m starting to see is a repeat of the 1990s. Each of the three major cloud vendors—Google, Amazon, and Microsoft—is producing a bunch of managed services, which are effectively commercial tooling they’re trying to get their customers to adopt. If you’re a Microsoft Azure customer and you bought into the collection of tooling that’s on Azure, they have you locked in because it’s hard to migrate from Azure to AWS [Amazon Web Services] if all your code is in proprietary tools.

这种数据分裂象征着角色孤岛的蔓延，阻碍了敏捷实施。正如接下来的三个客户故事所表明的那样，不断发展的技术有助于我们了解公司和软件开发组织必须工作的环境。

This data schism was emblematic of the spread of role-based silos that were impediments to agile implementation. The braid of constantly evolving technology helps us understand the environment in which companies and software development organizations had to work, as the next three customer stories indicate.

三个敏捷故事

Three agile stories

2003 年，我为都柏林的一家爱尔兰软件公司提供咨询。经理们关心进度和生产力，对提高绩效的敏捷方法很感兴趣——本质上，他们希望我为他们提供建议，帮助他们“解决”开发工作，尤其是进度延误的问题。在采访了开发人员、测试人员、主管和经理后，我得出结论，开发并不是造成进度延误的原因。决策才是！他们的总部在硅谷，似乎即使是很小的决定——主要是关于产品特性的决定——也需要总部 (HQ) 的批准。由于地处地球另一端，爱尔兰集团的优先事项经常被忽视，即使是很小的决定也需要时间来制定和实施。

I consulted with an Irish software company in Dublin in 2003. Managers were concerned with schedules and productivity and were interested in agile methods to improve performance—in essence, they wanted me to advise them on “fixing” their development efforts, particularly schedule delays. After interviewing developers, testers, supervisors, and managers, I concluded development was not the cause of the scheduling delays. Decision making was! Their home office was in the Silicon Valley, and it seemed that even minor decisions—about product features, primarily—required headquarters (HQ) approval. Being halfway around the world, the Irish group’s priorities were often overlooked, and even minor decisions took time to make and implement.

虽然我认为他们应该考虑敏捷方法，但首要任务是解决决策失误的问题。首先，他们需要一位都柏林团队的产品经理，与团队合作，在当地做出 80% 到 90% 的产品决策。他们还需要授权开发团队做出许多技术决策。这意味着将需要总部批准的决策缩减到少数。其次，总部员工需要缩短响应时间，并建议都柏林办公室记录请求和响应时间，直到情况好转。将决策权下放给团队可以增强团队的能力，在这种情况下，交付速度会大大加快。

While I thought they should think about agile methods, the first order of business was fixing their decision-making breakdown. First, they needed a product manager on the Dublin team who could work with the team to make 80% to 90% of the product decisions locally. They also needed to empower the dev team to make many of the technical decisions. This meant scaling back the decisions needing HQ approval to a small number. Second, HQ staff needed to shorten their response time, and suggested that the Dublin office keep a log of request and response times until the situation improved. Pushing decision making to the team level creates empowered teams, which in this case sped delivery considerably.

有时，项目管理修复是提高绩效的关键。在这次参与之后，我做了一些研究，惊讶地发现项目管理书籍甚至项目管理协会的知识体系中对决策的关注程度如此之低。我决定在我正在编写的项目管理书中纠正这一疏漏。

Sometimes, project management fixes are key to improved performance. After this engagement, I did some research and was amazed at how little attention was being paid to decision making in project management books and even in the Project Management Institute’s Body of Knowledge. I was motivated to correct that omission in the project management book I was working on.

互联网加速了印刷媒体的消亡。出版公司 (PCI) 是一家科学和研究期刊出版商，它面临着应对这种脱离印刷出版趋势的挑战。其美国分部在适应这一变化方面面临着艰巨的任务，因为其 IT 系统面向支持期刊、论文和书籍印刷和分发的内部应用程序。

THE INTERNET HASTENED the demise of print media. Publishing Company, Inc. (PCI), a publisher of scientific and research journals, faced the challenge of coping with this trend away from print publishing. Its U.S. division had a daunting task in adapting to this change, as its IT systems were geared toward internal applications that supported printing and distribution of journals, papers, and books.

在这十年中，许多组织都经历了类似的从纸质到在线的转变。像亚马逊这样的公司为其他公司在面向客户的应用程序方面提供了样板，但在幕后，它们的软件开发方法和实力却不那么引人注目。从杂志到报纸再到书籍，出版公司都面临着重大变革——不仅是在产品方面，而且在产品开发方式方面。出版业是互联网重塑的行业之一。对于许多这样的企业来说，它们成功的敏捷实施鼓励了其业务部门的方法和思维方式的转变。

During this decade, many organizations faced a similar paper-to-online transition. Companies like Amazon provided models of where others might go with customer-facing applications, but behind the scenes their software development methods and prowess were less visible. Publishing companies ranging from magazines to newspapers to books faced major upheavals—not only in their products, but also in how they developed their products. Publishing was one of those industries the Internet remade. For many of these enterprises, their successful agile implementations encouraged method and mindset changes in their business units.

Cutter Consortium 团队与 PCI 合作实施敏捷项目。团队成员包括 Mike Cohn、Josh Kerievsky、Ken Collier 和我。以下是 Ken 对 PCI 进展的评估经过高度编辑的版本：

A Cutter Consortium team worked with PCI on its agile implementation. The team included Mike Cohn, Josh Kerievsky, Ken Collier, and me. What follows is a highly edited version of Ken’s assessment of PCI’s progress:

我（肯）在 PCI 度过了最后两天，与乔纳森一起进行最后的辅导和评估。克里斯托有点担心“放弃训练”，但我向她保证我们可以回来。

I (Ken) spent the last two days at PCI alongside Jonathan doing our final coaching and assessment. Crystal is a bit concerned about “taking the training wheels off,” but I assured her we could come back.

到目前为止，该团队在采用敏捷技术和敏捷项目管理实践方面取得了良好的成功。虽然他们在测试驱动开发 (TDD) 和持续集成方面还有成长空间，但 Josh 和我都认为，对于一支只经历过 8 次迭代的新敏捷团队来说，他们的水平高于平均水平。一个弱点是估算和跟踪。昨天我进行了一小时的估算课程，教他们 Mike Cohn 的粗粒度估算故事点方法。我对结果感到很满意。

The team has had good success in adopting the agile technical and agile project management practices to date. While they have room for growth in test-driven development (TDD) and continuous integration, both Josh and I agreed they are above average for a new agile team with only eight iterations under their belt. One weakness was estimation and tracking. I ran a one-hour session on estimation yesterday, teaching them Mike Cohn’s methods of coarse-grained estimating in story points. I felt good about the outcome.

我担心内部敏捷教练的热情会让人觉得他是一个敏捷狂热分子。他不是一个引导者，而是倾向于指挥控制风格。我和他进行了一对一的会面，虽然他很防御，但我希望我的建议能促使他稍微收敛一点。

I was concerned that the internal agile coach, in his enthusiasm, came across as an agile zealot. Rather than being a facilitator, he tended to have a command-control style. I had a one-on-one meeting with him and while he was defensive, I hope my recommendations motivated him to tone it down a bit.

我（Jim）与 PCI 领导指导团队进行了通话，审查了我们的敏捷实践记分卡和对人际关系问题的评估。PCI 继续在其他开发团队中建立了敏捷方法。

I (Jim) had a call with the PCI leadership steering team to review our agile practice scorecard and our assessment of the interpersonal issues. PCI went on to establish an agile methodology in other development teams.

2003 年，我为 Mountain Region Health 举办了一次敏捷项目管理研讨会。他们有一位新任 CIO，他是 XP 的支持者。这位 CIO 决定，从今以后，所有项目都将使用 XP，包括刚刚开始的 100 人项目。该小组组织成 12 个 XP 团队，并开始了为期 2 周的迭代。对于几个迭代，速度（如后文所述，速度并不是一个好的绩效指标）稳步增加。然后速度发生了逆转。每个团队都独立运作，团队之间的依赖关系开始减缓进度——随着时间的推移，这种依赖关系急剧增加。

IN 2003, I CONDUCTED AN Agile Project Management workshop for Mountain Region Health. They had a new CIO who was an XP proponent. The CIO decided that henceforth all projects would utilize XP, including a just-under-way 100-person effort. The group organized into 12 XP teams and launched into 2-week iterations. For several iterations, velocity (as explained later, velocity isn’t a good performance metric) steadily increased. And then the velocity reversed course. Each team had operated independently, and interteam dependencies began to slow progress—dramatically over time.

公司认为我的敏捷项目管理研讨会可能会帮助公司扭转局面。我建议使用敏捷项目管理实践并进行一些组织变革，包括组建兼职团队间协调小组，负责处理诸如通用持续集成管道等基本问题。通过聘请架构师并利用我在研讨会上提出的理念，公司能够重新获得仅使用 XP 所取得的进展。

The company thought my Agile Project Management workshop might help right the ship. I recommended using agile project management practices and making a couple of organizational changes, including forming part-time interteam coordination groups who worked on fundamental issues like a common continuous integration pipeline. With the hiring of an architect and utilization of the concepts in my workshop, the company was able to regain the momentum that using XP alone had started.

这位客户遇到了敏捷社区才刚刚开始解决的一个问题——扩展。一些批评者用这样的“失败”来证明敏捷开发行不通。Mountain Region Health 忽视了 Kent Beck 的警告——XP 是为小团队设计的，而不是 12 个相互依赖的团队。更大的努力需要额外的结构。

This client had run into a problem that the agile community was only just beginning to address—scaling. Some detractors used “failures” like this to prove agile development didn’t work. Mountain Region Health had ignored Kent Beck’s caution—that XP was designed for small teams, not 12 interdependent teams. Additional structure would be needed for larger efforts.

敏捷项目管理

Agile project management

到 2002-2003 年，我开始思考项目管理 (PM) 问题，并开始转向咨询和教授 PM 以及起草一本敏捷 PM 书籍。分析从客户合作中得到的经验教训让我有很多思考：

By 2002–2003, I was thinking about project management (PM) issues and began pivoting to consulting and teaching PM and drafting an agile PM book. Analyzing the lessons learned from client engagements gave me plenty to think about:

• Agile 已成功交付成果（Alias Systems、Cellular 和 PCI）。

• Agile had successfully delivered results (Alias Systems, Cellular, and PCI).

• Agile 在探索性项目（Alias Systems 和 Cellular）中真正大放异彩。

• Agile really shined in projects that were exploratory (Alias Systems and Cellular).

• 从小型、同地团队项目转向更大规模的项目需要额外的 PM，但不是传统类型的 PM（Mountain Region Health）。

• Moving from small, co-located team projects to larger ones required additional PM, but not the traditional kind (Mountain Region Health).

• 正如以前的时代一样，组织结构、个人互动、协作团队和决策仍然对成功至关重要（爱尔兰软件公司和 Mountain Region Health）。

• As was true in previous eras, organizational structure, personal interactions, collaborative teams, and decision making were still critical to success (Irish software company and Mountain Region Health).

• 文化、个性和团队问题阻碍了更快的实施。

• Culture, personality, and team issues blocked faster implementation.

• 人们、团队和领导者很难采用敏捷思维。

• It was hard for people, teams, and leaders to adopt an agile mindset.

• 早期的敏捷专家是技术和/或项目管理专家，而不是心理学家或变革管理专家。我们需要帮助。

• Early agilists were technical and/or PM experts, not psychologists or change management experts. We needed help.

这些启示并非本章中介绍的客户故事所特有的，而是所有敏捷实践者都遇到的问题的体现。本章对敏捷项目管理的概述将涵盖其中大部分主题。其中两个主题——价值管理和组织变革——将在第 7 章中介绍。

These revelations are not unique to the client stories presented in this chapter, but rather were indicative of issues that all agile practitioners were encountering. Most of these topics will be covered in this chapter’s overview of agile PM. Two of them—value management and organizational change—are covered in Chapter 7.

我的书《敏捷项目管理：创造创新产品( APM )》于 2004 年出版（第二版于 2009 年出版；Highsmith，2009 年）。我想介绍管理项目和产品的方法、方法论和思维方式。Thoughtworks 创始人兼前首席执行官 Roy Singham 的推荐抓住了我写这本书的理由：“终于有一本书将敏捷软件运动的热情与项目管理所需的原则融为一体。Jim 的书为我们所有人提供了服务。”

My book Agile Project Management: Creating Innovative Products (APM) was published in 2004 (and a second edition in 2009; Highsmith, 2009). I wanted to present methods, methodology, and mindset for managing projects and products. The endorsement from Roy Singham, founder and former CEO of Thoughtworks, captured my rationale for writing it: “Finally a book that reconciles the passion of the Agile software movement with the needed disciplines of project management. Jim’s book has provided a service to all of us.”

敏捷运动源于对以不同方式开发软件的需求——采用迭代而不是串行方式，创建自组织的团队，并摒弃传统。敏捷主义者的普遍评论是“我们不需要任何项目管理”，其广义形式是“我们不需要任何管理”。人们创造了新的名字——迭代经理、产品所有者等——以表明摆脱传统角色。

The agile movement arose from a need to develop software differently—to be iterative instead of serial, to create teams that self-organized, and to eschew tradition. The general comment from agilists was “We don’t need any project management,” with the generalized form of that being “We don’t need any management.” New names were coined—iteration manager, product owner, and others—to indicate a move away from traditional roles.

我记得在 1990 年代曾与一位项目经理交谈过，他当时使用 SuperCalc（Excel 的早期竞争对手）作为他的 PM 工具。我问他多久走动一下，与团队成员交谈或召开简短的团队会议。“不经常，”他回答道。“在 SuperCalc 中保持任务信息更新占用了我所有的时间。”这种对任务而不是人的管理正是敏捷主义者所抱怨的。我们需要的是不同的 PM 风格——强调人及其互动（思维方式）而不是流程和工具（方法）；设想和探索（实验）而不是计划和执行；以及客户体验（思维方式）而不是记录的要求（方法）。

I remember talking with a project manager in the 1990s who was using SuperCalc (an early competitor to Excel) as his PM tool. I asked him how often he walked around and talked with his team members or had short team meetings. “Not often,” he replied. “Keeping the task information up-to-date in SuperCalc takes up all my time.” This management of tasks rather than people was what agilists were complaining about. What was needed was a different style of PM—one that emphasized people and their interactions (mindset) rather than process and tools (methods); envisioning and exploring (experimentation) rather than planning and doing; and customer experience (mindset) rather than documented requirements (methods).

在瀑布式生命周期的影响下，组织将项目经理置于一个单独的组织框架中——有时在 IT 部门内，有时不在。项目管理办公室 (PMO) 对 IT 团队来说，变成了项目警察，执行 Monumental 方法标准和阶段审查，而不是充当团队的 PM 顾问。

Under the influence of waterfall life cycles, organizations had placed project managers in a separate organizational box—sometimes within the IT department, sometimes not. Project management offices (PMOs) became, to the IT teams, the project police, enforcing Monumental Methodology standards and phase reviews, rather than acting as PM consultants to the teams.

我撰写《敏捷项目管理》（APM；Highsmith，2009）的目的是帮助弥合传统和敏捷项目管理方法之间的差距。指出每种方法的价值所在。向敏捷社区表明，需要一定的结构，特别是当项目越来越大时，才能避免陷入混乱。混乱并不比僵化好。图 6.1将设想—探索过程显示为两个集成循环。

My intent in writing Agile Project Management (APM; Highsmith, 2009) was to help bridge the gap between traditional and agile approaches to project management. To point out what was valuable in each. To show the agile community a bit of structure was needed, particularly as projects got bigger, to keep from falling into chaos. Chaos isn’t any better than rigidity. Figure 6.1 shows the envision–explore processes as two integrated cycles.

虽然 CYNEFIN模型在对变化速度和高级应对策略进行分类方面很有用，但我认为在项目或产品层面还需要进行额外的分类。为了满足这一需求，我在研讨会上引入了探索因素 (EF)，然后在APM书中引入了探索因素。

WHILE THE CYNEFIN model had been useful in categorizing the pace of change and high-level coping strategies, I thought additional categorization was needed at the project or product level. To meet this need, I introduced the exploration factor (EF) in my workshops and then in the APM book.

EF 是产品或项目不确定性和风险的晴雨表。大项目与小项目不同；高风险项目与低风险项目不同。识别各种问题域因素很重要，但更重要的是根据问题定制流程和实践并相应地调整期望。

An EF acts as a barometer of the uncertainty and risk of a product or project. Big projects are different from small projects; high-risk projects are different from low-risk ones. It is important to identify the various problem domain factors, but it is even more important to tailor processes and practices to the problem and to adjust expectations accordingly.

图 6.2中显示的 EF是根据产品需求（目的）的波动性以及其技术平台（手段）的新颖性（因此也具有不确定性）得出的。它由四类需求波动性（不稳定、波动、常规和稳定）和技术类别（前沿、前沿、熟悉和众所周知）决定。6^评级使用 4×4 表格确定，EF 值为 1-10，后者是最高探索级别。

The EF, shown in Figure 6.2, is derived from a combination of the volatility of a product’s requirements (ends) and the newness—and thus uncertainty—of its technology platform (means). It is determined by four categories of requirements volatility (erratic, fluctuating, routine, and stable) and technical categories (bleeding edge, leading edge, familiar, and well known).⁶ Ratings are determined using a four-by-four table with EF values of 1–10, with the latter being the highest level of exploration.

6.前 Sciex 员工 Ken Delcol 评论道：“这可以指导项目经理如何管理项目和单个需求。例如，不稳定的需求需要采用更具迭代性的方法，无论其余需求的整体状态如何，都应提前规划。并非所有需求都属于同一类别。诀窍在于认识到哪些需求是整个产品成功的关键——当关键的高风险需求不稳定或波动时，急于指定稳定的需求是没有意义的！”

6. Ken Delcol, formerly of Sciex, commented: “This guides the PM in both how the project and individual requirements should be managed. For example, erratic requirements need a more iterative approach and should be planned that way up front regardless of the overall state of the remaining requirements. Not all requirements fall into the same bucket. The trick is to realize which requirements are key to overall product success—there is no point rushing forward to specify the stable requirements when critical, high-risk requirements are erratic or fluctuating!”

通过确定 EF，团队现在可以讨论如何在问题空间的总体不确定性和风险下继续进行。将团队能力与项目 EF 相匹配应该像将登山队的能力与攀登特定山峰的能力相匹配一样周到。

By determining the EF, teams could now discuss how to proceed given the overall uncertainty and risk of the problem space. Matching team capability to project EF should be as thoughtful as matching a mountaineering team’s ability to climb a particular peak.

传统项目管理以及一般的组织管理通常基于恐惧——害怕管理者看起来不够坚定、无所不知、强大。“我的项目不会因为我个性中不屈不挠的意志而失败”可能是潜藏在表面之下的假设。承认不确定性、犯错的可能性或犯错会阻碍管理者和项目团队了解项目中最关键的方面。如果不改变思维方式，迭代生命周期通常不会比线性生命周期更好。

TRADITIONAL PM, AND organizational management in general, is often based on fear—fear a manager won’t appear resolute, all-knowing, and strong. “My project won’t fail because of the indomitable will of my own personality” may be the assumption lying just underneath the surface. Admitting uncertainty, the possibility of being wrong, or making a mistake keeps managers and project teams from learning about the most critical aspects of projects. Without a change in mindset, iterative life cycles are often no better than linear ones.

迭代生命周期使我们能够探索设计和需求——修改设计和原型设计以满足新需求——但它们很少延伸到认真检查整体 PM 问题，例如范围、进度、高管支持和客户参与。一个例子是我多年前为一家大型消费品公司的 IT 部门管理的一个项目。在向执行指导委员会制定项目计划时——多个周期，包括审查点、可交付成果等——我指出，我们在早期周期的目标是犯错误！幸运的是，没有立即发生叛变。我继续解释说，没有办法完成这样的项目而不犯错误，我们希望尽早犯错，这样我们就有时间纠正错误，最终得到正确的产品。

Iterative life cycles have allowed us to explore design and requirements—revising designs and prototyping for new requirements—but they rarely extend to seriously examining overall PM issues such as scope, schedule, executive sponsorship, and customer participation. An example was a project I managed years ago for an IT organization in a large consumer goods company. In laying out the project plan to the executive steering committee—multiple cycles with review points, deliverables, and so on—I made the point that our objective during the early cycles was to make mistakes! Lucky for me there wasn’t an immediate mutiny. I went on to explain there was no way to accomplish a project like this without mistakes, and we wanted to make mistakes early so we had time to correct them and end up with the right product.

果然，在第一个开发周期结束时，我们犯了一个大错误——就在执行指导委员会面前。项目团队对产品范围的困惑反映在一次杂乱无章的演示中，一些指导委员会成员心怀不满。值得赞扬的是，该组织允许团队重新集结，仔细思考问题，并与项目的执行发起人一起探索替代方案。团队（其中包括大量用户）随后花了几周时间重新审查项目范围和可交付成果。“解决方案”还包括对指导委员会本身进行彻底重组。指导委员会是根据上一个项目的失败而成立的，而不是根据当前项目的需求。

Sure enough, at the end of the first development cycle, we made a major blunder—right in front of the executive steering committee. The project team’s confusion over the product scope was reflected in a disorganized presentation and a few steering committee members left disgruntled. To this organization’s credit, the team was allowed to regroup, think through the issues, and explore alternatives with the executive sponsor of the project. The team (which included a significant user contingent) then spent an agonizing couple of weeks reexamining the project scope and deliverables. The “solution” also included a complete restructuring of the steering committee itself. The steering committee had been put together based on a previous project’s failure, not the current project’s needs.

这些都是惨痛的教训。项目团队在经历这样的评估时，难免会感到痛苦。然而，由于这次评估是基于交付的组件，而不是文档，团队无法逃脱严格的审查。评估是在项目开始后 5 周进行的，而不是 6 个月、9 个月或 12 个月后，团队有时间重组和恢复。早期面对问题有助于后来的成功。最后，尽管一些经理对最初的结果不太满意，但作为一个团队，他们允许团队跌倒然后恢复。

These were difficult lessons. A project team doesn’t go through an assessment like this without experiencing some painful emotions. However, as this review was based on delivered components, not documents, the team couldn’t escape critical scrutiny. The review occurred 5 weeks after the project started, not 6 or 9 or 12 months later, and the team had time to regroup and recover. Having to face problems early contributed to later success. Finally, although some of the managers weren’t too happy about the initial results, as a group they allowed the team to stumble and then recover.

随着敏捷运动从“流氓团队”时代转变为“勇敢的高管”时代，项目和产品管理的重要性日益增加。

As the agile movement transitioned from the Rogue Teams era to the Courageous Executives era, both project and product management would increase in importance.

期间观察

Period observations

有些人拒绝参与结对编程。有些人认为敏捷团队开会太多。项目经理反抗，因为他们不再管理任务，而是他们的团队管理。Scrum 领导者很难定义自己的角色，尽管 Scrum 文献和研讨会上似乎已经明确了这一点。需要提高协调技能。谁做了哪些决定？这里发生了什么？

Some individuals refused to engage in pair programming. Some thought agile teams had too many meetings. Project managers rebelled because they no longer managed tasks; instead, their teams did. Scrum leaders struggled with defining their roles, even though it seemed to be spelled out in the Scrum literature and workshops. Facilitation skills needed to improve. Who made which decisions? What was going on here?

从某些方面来看，实施敏捷技术实践很容易。当然，从智力上来说很难，但从社交上来说并不难（结对编程是个例外）。敏捷协作实践——没有物理障碍的同地团队，与其他人密切合作（每天！），角色和职责混乱，在开发团队中增加测试人员和产品负责人，接受团队责任的脆弱性，中层管理人员不确定自己的角色——融入社会和人际挑战是敏捷采用的最大障碍。

In some ways, implementing agile technical practices was easy. It was difficult intellectually, for sure—but not socially (an exception would be pair programming). Agile collaboration practices—co-located teams without physical barriers, working closely with other people (every day!), confusion over roles and responsibilities, adding testers and product owners to dev teams, tenuousness about accepting team accountability, middle managers unsure about their role—incorporating the social and interpersonal challenges were the greatest impediments to agile adoption.

敏捷时代的第一阶段带来了好坏参半的结果。许多经理对项目绩效、更好的投资回报、更快的结果、更高的质量和更好的客户关系感到满意。那些同时采用团队管理和技术实践的组织在提高质量和整体成果方面有更好的记录。

This first period of the Agile era led to mixed results. Many managers were pleased with project performance, better return on investment, faster results, higher quality, and improved customer relationships. Those organizations utilizing both team management and technical practices had a better record of improving both quality and overall results.

在第 4 章中，我提到了为提供更好的软件而苦苦思索的目的陈述。当时，我还没有想出一个我喜欢的陈述。现在是时候再试一次了。

IN CHAPTER 4, I mentioned wrestling with a purpose statement about delivering better software. At that time, I had not yet come up with a statement I liked. Now it was time to try again.

Jerry Weinberg 的系列丛书《软件质量管理》第一至第四卷，共 1,538 页。任何人都可以说他们喜欢“优秀”或“高”质量，但这些形容词用得太多了，基本上毫无意义。在旁观者眼中，质量的本质等同于运行/测试的代码，还是其他什么？您是否认为对 Facebook 最新功能的测试应该像对詹姆斯韦伯太空望远镜软件的测试一样严格？

Jerry Weinberg’s book series, Software Quality Management, volumes I–IV, runs some 1,538 pages. Anyone can say they are in favor of “excellent” or “high” quality, but those adjectives are so overworked they are essentially meaningless. Is quality intrinsic, in the eye of the beholder, equivalent to running/tested code, or something else? Do you think the testing for the latest Facebook features should be as intense as that for the James Webb Space Telescope software?

杰里对质量的定义长达 1,500 页，需要读完才能完全理解其中的细微差别，但他给出的定义却简单得令人难以置信：“质量就是对某些人的价值。” ⁷现在，我们要做的就是清楚地说明“价值”和“某些人”的含义。

After 1,500 pages, which need to be read to fully understand the nuances, Jerry’s definition of quality was deceptively simple: “Quality is value to some person.”⁷ Now, all we must do is articulate what is meant by “value” and “some person.”

7.Weinberg，1992，第 7 页。

7. Weinberg, 1992, p. 7.

Jerry对质量的定义帮助我扩展了我的个人目标声明，以实现更好的软件交付：“通过创建先进的软件和管理方法、方法论和思维方式，实现持续交付客户价值。”

Jerry’s definition of quality assisted me in extending my personal purpose statement for better software delivery: “To enable the continuous delivery of customer value by creating advanced software and management methods, methodologies, and mindsets.”

我知道这句话有点冗长，但这句话包含对我来说很重要的元素。首先，它符合杰里的定义，将价值和人的概念融入到客户中。其次，它说我致力于“创造先进的软件和项目管理、方法、方法论和思维方式”。持续交付 (CD) 需要卓越的技术。我说的 CD 不是自动化测试和部署管道意义上的 CD，尽管这可能是一个关键部分。相反，我正在解决 CD 的另一个层次，即构建发布支持客户的软件版本的能力，第十个版本与第一个版本一样容易。

I know it’s a little wordy, but this statement contains elements important to me. First, it conforms to Jerry’s definition by incorporating the notions of value and person in the form of a customer. Second, it says I’ve devoted a career to “creating advanced software and project management, methods, methodologies, and mindsets.” Continuous delivery (CD) requires technical excellence. I’m not speaking about CD in the sense of an automated testing and deployment pipeline, although that might be a key piece. Instead, I’m addressing another level of CD, building the capability of releasing versions of software supporting customers as easily with the tenth version as with the first.

在第 8 章中，关于质量的叙述将与其他两个组成部分（价值和约束）相结合，构建与敏捷方法一致的企业绩效管理模型。

In Chapter 8, this narrative on quality will be combined with two other components, value and constraints, to build an enterprise performance management model consistent with agile methodologies.

为什么巨型方法论逐渐式微，而敏捷方法论逐渐兴起？仔细研究任何一种巨型方法论 — — STRADIS、DSSD、Method/1 或 RUP。它们要求我们“做”某事 — — 图表、文档、流程、审批等。但它们缺乏为决策提供依据的价值观陈述。个人很难决定如何适应这些方法，因为他们没有比较的价值观陈述。敏捷宣言的价值观 — —个体和交互高于流程和工具— — 表达了敏捷主义者的信念，即思维方式为决策提供了标准。没有任何一种巨型方法论明确声明它们重视什么。因此，人们做出了假设，例如“我猜他们重视文档，因为文档太多了。”

Why did Monumental Methodologies fade, and agile methodologies ascend? Examine closely any of the Monumental Methodologies—STRADIS, DSSD, Method/1, or RUP. They tasked us to “do” something—diagrams, documents, processes, approvals, etc. But they were short on value statements that provided a basis for making decisions. Individuals had a difficult time deciding how to adapt these approaches because they didn’t have comparative value statements. The Agile Manifesto value—Individuals and interactions over processes and tools—expresses what agilists believe, that a mindset provides a criterion for decision making. None of the Monumental Methodologies declared, explicitly, what they valued. People, therefore, made assumptions, like “I guess they value documentation given that there is so much of it.”

我在《敏捷软件开发生态系统》一书的最后一章中总结了对 Rogue Teams 时期末期敏捷运动状态的观察：

My observation of the state of the agile movement at the end of the Rogue Teams period is summed up in the last chapter of my Agile Software Development Ecosystems book:

在某些方面，我们敏捷主义者就像堂吉诃德和他的伙伴桑丘·潘沙，在软件开发领域四处奔走，与传统主义的风车作斗争。我们在这里和那里取得了一些成就，但大多数大型企业和政府发展部门仍然持怀疑态度。即使在团队成功实施敏捷项目的组织中，他们的同行也常常不相信。对于挑战现状的新事物，情况总是如此。（Highsmith，2002 年，第 381 页）

In some ways, we Agilists are like Don Quixote and his sidekick, Sancho Panza, riding around the software development landscape, tilting at the windmills of traditionalism. We’ve made dents here and there, but the bulk of large corporate and governmental development remains skeptical. Even in organizations in which teams have successfully implemented Agile projects, their peers often remain unconvinced. This is always the case with something new that challenges the status quo. (Highsmith, 2002, p. 381)

科学克斯

Sciex

MDS Sciex 为生命科学、制药和法医分析客户开发质谱仪（和其他仪器）。从 2004 年到 2006 年，我在加拿大多伦多与这家公司合作，实施由极限编程 (XP) 和 APM 组成的敏捷“组合”方法。我们与 Josh Kerievsky 和其他 Cutter Consortium 顾问一起，最初与软件团队合作，然后将选定的敏捷实践扩展到其他工程团队。

MDS Sciex develops mass spectrometers (and other instruments) for life sciences, pharmaceutical, and forensic analysis customers. From 2004 through 2006, I worked in Toronto, Canada, with this company to implement an agile “combo” methodology consisting of Extreme Programming (XP) and APM. Along with Josh Kerievsky and other Cutter Consortium consultants, we initially worked with software teams and then extended selected agile practices into other engineering groups.

在 2022 年的一次电子邮件交流中，Gary Walker（当时的软件开发经理）传达了 Sciex 当时存在的情况及其敏捷实施的结果。

In an email exchange in 2022, Gary Walker (then manager of software development) conveyed the situation that then existed at Sciex and the results of its agile implementation.

在确定是否需要“改造我们的开发组织”时，我们很快意识到我们真的别无选择！我们的仪器软件有几百万行代码，充斥着多年的技术债务。每个新的修复或功能都只会带来意想不到的新问题，而且每个新版本都比上一个更不稳定。1^不稳定的软件对我们的“大型制药公司”药物发现和开发客户来说是一个巨大的问题；当我们的软件崩溃时，他们通常会丢失花费数周时间创建的实验药物样本。甚至竞争对手在他们的营销材料中提到我们的软件时也打出了这样的口号：“我们的软件不会崩溃。”

In determining whether we needed to “transform our development organization,” we quickly realized we really didn’t have a choice! Our instrument software was a couple of million lines of code riddled with years of technical debt. Every new fix or feature just created unexpected new problems, and each new release was more unstable than the last.¹ Unstable software was a huge problem for our “Big Pharma” drug discovery and development customers; when our software crashed, they often lost an experimental drug sample that took weeks to create. Even competitors referred to our software in their marketing materials with slogans like “Our software won’t crash.”

1.作为技术债务的直观演示，Josh Kerievsky 从他们的一个物体中打印出一种方法。将纸张首尾相连地铺在地板上，该方法长达 10 英尺以上！

1. Josh Kerievsky, as a visual demonstration of tech debt, printed out a method from one of their objects. Laying the pages end-to-end on the floor, the method was more than 10 feet long!

这对我们的开发团队产生了巨大影响。他们非常担心在这个庞大而不稳定的代码库中添加新功能；因此，他们通常会“采取最安全的开发路线”，给代码库增加更多的技术债务。他们对产品毫无自豪感，开发人员会把客户的反馈当成是针对他们个人的。

This had an immense impact on our development teams. They were very nervous to add new functionality to this huge unstable code base; hence, they would usually “take the safest possible development route,” adding even more technical debt to the code base. There was no pride in the product and the developers would take customers’ feedback personally.

我记得，在我们启动敏捷转型大约 18 个月后，我们开始看到团队思维方式和行为的变化。来自 Cutter 团队的硬数据表明，开发团队现在能够以更快的速度和更低的成本交付更高质量的产品。来自我们客户的反馈开始变得更加积极。这对团队成员的思维方式和开发社区的整体环境产生了巨大影响。开发人员再次对自己的技能充满信心，并对他们向客户交付的产品感到自豪。

As I recall, we began to see a change in the team mindset and behavior approximately 18 months after we initiated the Agile transformation. Hard data from the Cutter team showed the development teams were now delivering higher-quality product releases faster and at lower cost. Feedback from our customers was starting to be more positive. This had a huge impact on the team members’ mindset and the overall environment for the development community. Developers were once again feeling confident in their skills and pride in the product they were delivering to our customers.

此外，敏捷原则、价值观和实践提供了培养“心理安全”环境的框架（Edmondson，2002）。团队成员经常互相挑战，推动团队创造更具创意和更高质量的产品功能。再一次，工作变得有趣了！

Also, the Agile principles, values, and practices provided the framework to foster an environment of “psychological safety” (Edmondson, 2002). Team members regularly challenged each other, pushing the team to generate more creative and higher-quality product features. Once again, it had become fun to come to work!

Sciex 是一家获得 ISO 认证的组织。与许多公司一样，这是一项业务要求——我们的客户也期待这一点。这一点尤其重要，因为我们在为药物研发行业的国际制药公司。

Sciex was an ISO-certified organization. Like many companies, this was a business requirement—our customers expected it. This was especially critical because we were developing high-end instruments for international pharmaceutical companies in the drug discovery and development industry.

我们必须努力解决这一问题：如何协调 Agile 的迭代适应性实践与 ISO 的要求？这些要求主要基于瀑布式交付的 Big Up-Front Design (BUFD) 原则，并依赖于对流程、计划和记录结果的严格记录。

We had to grapple with the question: How do we reconcile the iterative adaptive practices of Agile to the requirements of ISO? Those requirements were based very much on the Big Up-Front Design (BUFD) principles of waterfall delivery, and relied on rigorous documentation of processes, plans, and recorded results.

^{我们与 Jim 和 Josh 2}合作，提出了区分“治理”和“执行”的概念。治理侧重于“时间和金钱”（即时间表和预算）。我们在治理层面应用了规划和执行文档，以满足持续 ISO 认证的需求。

Working with Jim and Josh,² we developed the concept of distinguishing “governance” from “execution.” Governance focused on “time and money” (i.e., schedule and budget). We applied the planning and execution documentation at the governance level to meet the needs for continued ISO certification.

2. Josh 和我后来在本章后面描述的中国电信合作项目中使用了这种方法。

2. Josh and I later used this approach in our Telecom China engagement described later in this chapter.

而且，我们在“执行”层面应用了敏捷原则和实践，从而在极端不确定的环境中（业务、科学和技术）充分利用了敏捷执行的优势。这让我们“鱼与熊掌兼得”。我们利用敏捷的优势进行执行，并满足了 ISO 认证的需求。

And we applied the Agile principles and practices at the “execution” level, thereby leveraging the benefits of Agile execution in our context of extreme uncertainty (business, scientific and technical). This allowed us to “have our cake and eat it, too.” We leveraged the benefits of Agile for execution and addressed the needs of ISO certification.

我们从一个软件项目开始实施 Sciex 敏捷方法。当时，员工们都坐在各自的办公室里，因此 Josh 和我说服他们创建一个团队工作区。有时，最无害的障碍也会成为阻碍——例如按时订购和交付硬件，或者在这种情况下让建筑维护人员建造新的工作区。当空间部分完工时，建筑人员就离开了，去度周末。开发团队在一个周末偷偷完成了空间，以便周一早上开始工作，这让维护经理非常懊恼。

We started the Sciex agile implementation with a software project. Staff were then sitting in individual offices, so Josh and I convinced them to create a team workspace. Sometimes the most innocuous impediments get in the way—like getting hardware ordered and delivered on time, or in this case getting the building maintenance crew to build out the new workspace. With the space partially completed, the building crew left for the weekend. The dev team surreptitiously completed the space over a weekend so work could start Monday morning, much to the chagrin of the maintenance manager.

Josh 和其他顾问与团队合作，制定了 XP 的技术实践。我负责组织、项目管理以及管理实践和问题。在我们举办了几次研讨会的同时，Josh 和我再次确认，与团队的日常合作对于成功确实至关重要。

Josh and other consultants worked with the teams to institute technical practices from XP. I worked on organizational, project management, and management practices and issues. While we conducted several workshops, Josh and I confirmed, again, that working day-to-day with teams was really critical to success.

在我们成功完成几个项目后，产品管理总监 Ken Delcol 决定使用敏捷开发来开发他们的下一代质谱仪产品——这是一个非常勇敢的举措，因为在软硬件组合项目中使用敏捷方法是一项艰巨的任务。我们的场外项目愿景和启动会议包括软件开发人员；机械、电气和系统工程师；几位科学家；产品经理；以及一名采购分析师。在制定整个项目时间表时，采购分析师发挥了重要作用，因为他知道许多组件的交付周期^。3

With several successful projects under our belts, Ken Delcol (director of product management) made the call to use agile development for their next-generation mass spectrometer instrument product—a hugely courageous step, as using agile methods in a combination hardware/software project was a big stretch. Our off-site project visioning and kick-off meeting included software developers; mechanical, electrical, and systems engineers; several scientists; product managers; and a purchasing analyst. In laying out the total project timeline, the purchasing analyst was invaluable since he knew the lead time for many of the components.³

3.你并不总是能提前知道谁会提供关键信息。

3. You don’t always know ahead of time who will supply critical pieces of information.

结束了令人精疲力竭但成果颇丰的一周后，肯回来回顾进展。他开启了第一天的工作，为新产品建立了高管视角。每个人都迫不及待地想回到办公室开始工作，但肯还有另一个惊喜。

At the end of an exhausting but productive week, Ken returned to review progress. He had kicked off the first day, establishing an executive perspective for the new product. Everyone was eager to get back to their offices and get to work, but Ken had one more surprise.

“最后一件事，”肯在一天结束时说。“你们不会再回到你们各自的办公室。在你们离开校园的这一周里，我们重组了你们的整个工作区域以加强协作，这是你们本周工作的延续。你们现在是一个跨职能的产品团队，负责将这个产品推向市场。”最终，肯将整个产品开发部门从个人办公室重新配置为三种规模的团队区域——小、中、大。

“One last thing,” Ken said in wrapping up the day. “You will not be going back to your individual offices. During your week here off-campus, we have restructured your entire work area to enhance collaboration, a continuation of what you have done this week. You are now a cross-functional product team responsible for delivering this product to market.” Eventually Ken reconfigured the entire product development department from individual offices to team areas in three sizes—small, medium, and large.

大型系统最棘手的问题一直是将各个部分整合在一起，而这在历史上往往发生在最后关头。从软件到汽车再到工业控制系统，我们得到的教训都是相同的：整合的频率越低，发现和修复整合问题就越困难，成本也越高。敏捷实践使团队能够尽早且频繁地进行整合，从而大大减少了这一最后阶段的问题。

The gnarliest problem with big systems has always been integrating the various pieces, which historically occurred near the end when the clock was ticking. From software to automobiles to industrial control systems, the lesson learned had been the same: The less frequent the integration, the more difficult and expensive it was to find and fix integration problems. Agile practices enabled teams to integrate early and often, substantially reducing this endgame problem.

Ken Delcol 在 MDS Sciex 使用了这种方法。

Ken Delcol used this approach at MDS Sciex.

我们刚刚经历了这个过程。我们的固件组根据测试计划，以迭代方式将固件交付给硬件组。一旦确认了足够的功能，软件组就会加入进来添加应用程序。通过这种方法，我们不需要完全填充的数字板来开始固件和硬件集成测试。我们取得了几项成就（这是我们取得的最好成就）：集成测试开始得更快，因此问题得到更快的解决（更好的时间表和成本）；一旦最少的硬件到位，集成就会持续进行，因此不会出现资源高峰；由于所有组都参与了集成，因此沟通得到了改善。

We have just gone through this process. Our firmware group delivered firmware to the hardware group in iterations based on its testing schedule. Once sufficient functionality was confirmed, the software group was brought in to add applications. With this approach we didn’t need a fully populated digital board to begin firmware and hardware integration testing. We achieved several things (the best we have ever achieved): Integration testing started sooner, hence issues were resolved more quickly (better schedule and cost); integration was continuous once minimal hardware was in place, hence no peak in resources; and communication was improved because all groups participated in the integration.

Ken、Paul 和 Gary 为敏捷的未来制定了愿景，为这项工作提供了适当的资源支持，在员工焦虑时期给予鼓励，并且他们自己也真正了解敏捷方法。Josh 和我为经理和高管举办了研讨会，并与他们一起培养敏捷思维和理解敏捷方法。这种敏捷转型工作影响了软件和硬件开发，推动了最先进的技术发展。

Ken, Paul, and Gary created a vision for their agile future, supported the effort with appropriate resources, encouraged their staff during periods of anxiety, and were truly knowledgeable about agile approaches themselves. Josh and I conducted workshops for the managers and executives and worked with them on developing agile mindsets and understanding agile methods. This agile transition effort impacted both software and hardware development—advancing the state of the art.

新一代先驱者

A new generation of pioneers

在担任勇敢的高管期间，我结识了新朋友，与客户合作进行 CIO 级敏捷实施，编写了《敏捷项目管理》第二版（Highsmith，2009），并创建了敏捷项目领导网络（第 5 章介绍）。

During this Courageous Executives period, I met new people, worked with clients on CIO-level agile implementations, wrote the second edition of Agile Project Management (Highsmith, 2009), and founded the Agile Project Leadership Network (covered in Chapter 5).

早些时候，我认识了 GAP 的 Pat Reed，他曾在迪士尼和其他公司任职。Pat 邀请我去 GAP 讨论价值和敏捷三角。她当时是互联网交付管理服务（投资组合、项目和发布管理、IT 财务和战略、审计和质量）的总监。正如您所见，她是一个充满活力、充满想法、永不停歇的读者，精力充沛。她在自己的部门推行了敏捷开发，成为敏捷管理和适应性领导的先驱。GAP 的企业 IT 团队曾尝试过一个敏捷试点项目并取得成功，但在扩展敏捷实践方面遇到了困难，并且不相信敏捷方法可以用于他们的遗留系统工作。许多遗留 IT 组织都处于类似的境地，背负着遗留系统带来的沉重技术债务，当时这些团队只有一个模糊的敏捷实践实施路线图。

Early on, I met Pat Reed, of the GAP, who had previously held positions at Disney and other companies. Pat invited me to the GAP to talk about value and the Agile Triangle. She was then director of Internet delivery management services (portfolio, project and release management, IT finance and strategy, audits and quality). As you will see, she is a whirlwind, full of ideas, an incessant reader who possesses boundless energy. She had instituted agile development in her department and became a pioneer in agile management and adaptive leadership. The GAP’s corporate IT group had experimented with an agile pilot project with success, but struggled to scale agile practices and were unconvinced agile methods could be used in their legacy systems work. Many legacy IT organizations were in a similar situation, burdened by overwhelming technical debt from their legacy systems, with only a fuzzy roadmap for implementing agile practices in these groups at that time.

帕特和我开始讨论在年度敏捷开发大会上增加高管论坛，以满足高管们对了解采用和扩展敏捷开发的最新策略和最佳实践的日益增长的需求。高管​​论坛于 2011 年在盐湖城举行的敏捷开发大会上首次亮相。主会场正在庆祝《敏捷宣言》发表 10 周年，因此帕特和我确定了高管主题“现在是企业敏捷的时代”，以及以下会议愿景声明：“为高管们创造非凡而宝贵的体验，让他们能够通过融合敏捷交付、敏捷领导力和先进技术来联系和参与，探索未来十年的商业机会和挑战。”

Pat and I started a discussion about adding an Executive Forum to the annual Agile Development Conference to meet the growing demand by senior executives to learn about the latest strategies and best practices for adopting and scaling agile development. The Executive Forum debuted at the Agile Development Conference in 2011, in Salt Lake City. The main conference was celebrating the 10th anniversary of the Agile Manifesto, so Pat and I settled on the executive theme, “Now is the time for enterprise agility,” and the following conference vision statement: “To create an extraordinary and valuable experience for executives where they can connect and engage to explore the business opportunities and challenges of the next decade by blending Agile delivery, Agile leadership, and advanced technologies.”

首届高管论坛专为高级管理人员而设计，吸引了 7 位国际高管、13 位 C 级高管和 23 位副总裁级高管。作为敏捷联盟年度会议的一部分，该论坛让高管们能够在为期一周的活动中参加会议主题演讲和其他非高管会议。

This first Executive Forum, which was designed exclusively for senior executives, attracted 7 international, 13 C-level, and 23 vice president–level executives. Launching the forum as part of the Agile Alliance annual conference enabled executives to attend conference keynotes and other non-executive sessions throughout the week-long event.

2010 年，Pat 回答了火人节项目 Playa Info 经理 Rob Oliver 的询问，随后在旧金山市中心与火人节项目的 CEO、CIO 和其他员工共进午餐。当时我对火人节了解不多，在吃了一顿启发性的午餐后，我决定喜欢他们的冒险精神。这似乎是拥抱敏捷性的组织，因为他们有兼容的原则和受霍皮族长老智慧启发的使命。（火人节的原则包括彻底的包容、赠予、去商品化、彻底的自力更生、彻底的自我表达、社区努力、公民责任、不留痕迹、参与和即时性。）

In 2010, Pat fielded an inquiry from Rob Oliver, manager of Playa Info at the Burning Man Project, which led to a lunch in downtown San Francisco with the CEO, CIO, and other staff from the Burning Man Project. I didn’t know much about Burning Man at the time, and after an enlightening lunch, decided I liked their adventurous spirit. This seemed like just the organization to embrace agility, as they had compatible principles and a mission inspired by wisdom from Hopi elders. (Burning Man principles include radical inclusion, gifting, decommodification, radical self-reliance, radical self-expression, communal effort, civic responsibility, leaving no trace, participation, and immediacy.)

Pat 过去和现在都是新想法的源泉。她设想了一个敏捷管理课程，并说服旧金山的伯克利大学推广计划主管尝试开设一门课程。Pat 和我组成了顾问委员会并组织了研讨会，我前往旧金山共同教授第一堂课。这是一次有趣的经历，与会者包括 IT 经理以及数量惊人的非 IT 经理。我喜欢和 Pat 一起教这门课，但从亚利桑那州弗拉格斯塔夫到湾区的往返行程抵消了我作为兼职教授的微薄报酬。Pat 继续扩展课程，超越最初的课程，包括敏捷管理基础知识、原则和实践；APM；敏捷管理精通；敏捷产品所有权；交付管理；价值创新。

Pat was, and is, a fountain of new ideas. She envisioned an agile management curriculum and convinced Berkeley University extension program executives in San Francisco to experiment with a class. Pat and I formed the advisory council and put together the workshop, and I traveled to San Francisco to co-teach the first class. It was a fun experience, with attendees including IT managers as well as a surprising number of non-IT managers. I enjoyed teaching this class with Pat, but the travel back and forth from Flagstaff, Arizona, to the Bay Area negated my meager compensation as an adjunct professor. Pat has continued expanding the curriculum beyond the initial offerings to include agile management fundamentals, principles, and practices; APM; agile management mastery; agile product ownership; delivery management; and value innovation.

在本章前面的 Sciex 故事中，以及接下来介绍的客户故事中——综合金融软件、南方金融软件和中国电信——我的合作伙伴是另一位敏捷先驱和户外探险家 Josh Kerievsky。Josh 创立了一家专注于 XP 和推进最新技术的公司——通常先与自己的开发人员一起试验这些方法。他的公司 Industrial Logic, Inc. 已发展到拥有 50 多名员工和顾问。Josh 是第一批将 XP 的两周迭代转变为持续交付的人之一。他还在开发的人性方面进行了实验，例如制定有关项目个人安全的想法。Josh 是《重构模式》（Kerievsky，2005 年）和《敏捷的乐趣》（Kerievsky，2023 年）的作者。他发起了我们的皮哈峡谷之旅，再次展示了先驱者的冒险特质。

In the Sciex story earlier in this chapter, and in the next client stories presented here—Integrated Financial Software, Southern Financial Software, and Telecom China—my partner was yet another agile pioneer and outdoor adventurer, Josh Kerievsky. Josh founded a company focused on XP and advancing the state of the art—usually experimenting with the methods with his own development staff first. His company, Industrial Logic, Inc., has grown to more than 50 staff and consultants. Josh was one of the first to experiment by turning XP’s two-week iterations into continuous delivery. He has also experimented on the human side of development, such as formulating ideas about personal safety on projects. Josh is the author of Refactoring to Patterns (Kerievsky, 2005) and the Joy of Agility (Kerievsky, 2023). He initiated our Piha Canyon trip, once again demonstrating the adventurous trait of pioneers.

2010 年 5 月，我在明尼苏达州明尼阿波利斯举行的卡内基梅隆软件工程学院 (SEI) 架构技术用户网络会议 (SATURN 2010) 上发表了主题演讲。SEI 研究、技术和系统解决方案项目总监 Linda Northrop 表示：“Jim 能够阐述团队合作、规划和适应不断变化的环境的重要性。”这样的邀请表明敏捷运动正在继续推进成为软件开发的主流。

In May 2010, I presented a keynote address for the Carnegie Mellon Software Engineering Institute’s (SEI) Architecture Technology User Network Conference (SATURN 2010), in Minneapolis, Minnesota. Linda Northrop, director of SEI’s Research, Technology, and System Solutions Program, said, “What Jim brings to the table is the ability to describe the importance of teamwork, planning, and adaptation to ever-changing environments.” Invitations such as this one showed that the agile movement was continuing to advance into the mainstream of software development.

综合财务软件

Integrated Financial Software

2005 年，当我担任 Cutter Consortium 的 APM 总监时，我们在 Integrated Financial Software (IFS) 进行了大规模敏捷实施。我在这个故事中加入了其他几个项目的一些内容，并将进行详细介绍，因为我们的发现和解决方案是勇敢高管时期遇到的典型问题（并且今天仍然在遇到）。

In 2005, while I was director of APM at Cutter Consortium, we undertook a large-scale agile implementation at Integrated Financial Software (IFS). I’ve included aspects from several other engagements in this story and will go into considerable detail, as our findings and solutions were typical of those encountered during the Courageous Executives period (and are still being encountered today).

我们的合作始于对软件产品部门的全面评估。Cutter 的核心团队包括 Josh Kerievsky、几位顾问，以及我作为项目经理。

Our engagement began with a comprehensive assessment of the Software Products Division. The core Cutter team included Josh Kerievsky, several consultants, and me as the engagement manager.

正如许多像 IFS 这样的成功公司所发现的那样，他们需要提高自己的业绩，因为竞争对手正在获得发展，而客户对功能的要求也越来越高。IFS 拥有庞大的客户群和老化的遗留软件，这些软件的技术债务适中。新的竞争对手没有受到遗留软件的负担，因此能够更快地提供功能改进。20 世纪 90 年代，客户端-服务器系统的快速扩张也让 IFS 受到了重创。就在该公司将其产品转换为客户端-服务器架构时，互联网的爆炸式增长也要求进一步的技术转型。

As many successful companies like IFS were finding, they needed to improve their performance because competitors were gaining traction and customers were demanding ever more features. IFS had a large customer base and aging legacy software that had moderate technical debt. New competitors, less burdened by legacy software, offered faster feature improvements. IFS had also been whipsawed by the rapid expansion of client-server systems in the 1990s. Just as the company had converted its products to client-server architectures, the explosion of the Internet required a further technology transition.

我们的调查结果证实了管理层的担忧，即尽管组织的整体绩效和交付能力符合行业标准，但并非世界一流。他们的许多绩效指标都朝着错误的方向发展：生产力下降；组织在应对增长和产品复杂性方面不堪重负；质量和产品适应性下降；整体交付能力不足以及技术技能和领域知识的流失影响了按计划交付的能力。所有这些趋势都受到增长的影响。

Our findings confirmed management’s concerns that while the overall performance and delivery capability of the organization were within industry norms, they were not world-class. Many of their performance measures were trending in the wrong direction: Productivity was declining; the organization was straining to handle growth and product complexity; quality and product adaptability were declining; and the ability to deliver to plans was troubled by deficiencies in overall delivery capabilities and an erosion of technical skills and domain knowledge. All these trends were impacted by growth.

在早期向员工介绍向敏捷方法的过渡时，首席信息官 Dan 提出了一个问题：“为什么要引入敏捷？我们不必改变。我们并没有‘破产’。产品正在出货。公司正在发展。”然而，他继续解释了不断增长的“规模成本”——对 75 名工程师交付 5 种产品有效的方法，可能并不适用于 400 名工程师交付 12 种产品。

In an early presentation to his staff about the transition to agile methods, Dan, the CIO, posed the question, “Why introduce agile? We didn’t have to change. We weren’t ‘broken.’ Products are getting shipped. The company is growing.” However, he went on to explain the growing “costs of scale”—what worked well for 75 engineers delivering 5 products might not be best for 400 engineers delivering 12 products.

这些问题的警告信号比比皆是：质量——问题报告很高；功能——调试所花费的时间增加，创建新功能所花费的时间减少；可预测性——最近三个“年度”版本都延长了几个月；而且没有乐趣——人们被日益增长的挑战压得喘不过气来。

Warning signs of these issues abounded: quality—problem reports felt high; features—increasing time spent on debugging, decreasing time spent creating new features; predictability—the last three “annual” releases each had extended several additional months; and no fun—people were getting worn down by the growing challenges.

丹对这次合作有三个主要目标：

Dan had three key objectives for the engagement:

1. 评估绩效。

2. Assess performance.

3. 采用敏捷方法。

4. Adopt an agile methodology.

5. 根据改进建议采取行动。

6. Act on improvement recommendations.

我们的评估包括与经理、主管以及质量保证 (QA)、开发、产品管理、架构和人力资源部门的员工进行的一系列访谈。

Our assessment consisted of a series of interviews with managers and directors as well as staff from quality assurance (QA), development, product management, architecture, and human resources.

评估结果分为几类：

The results of the assessment fell into several categories:

• 缺乏跨职能团队

• Lack of cross-functional teams

• 质量问题

• Issues with quality

• 基于愿望的规划

• Wish-based planning

• 瀑布生命周期

• Waterfall life cycle

• 技术技能

• Technical skills

虽然并非所有人都认同需要进行哪些类型的变革，但他们支持变革的必要性，并似乎愿意尝试新方法。成功的项目和发布是承诺和辛勤工作的结果，但有时人们觉得自己的努力没有得到认可。人们希望提高绩效：“我们以前做过项目事后分析，但似乎什么都没有改变。”

Not everyone agreed on the types of changes needed, but they were supportive of the need for change and appeared willing to try new methods. Successful projects and releases had been the result of commitment and hard work, but sometimes people didn’t feel recognized for their efforts. People wanted to improve performance: “We’ve done project postmortems before, but nothing seems to change.”

当面临与规模和复杂性相关的压力时，团队活力和关系往往会受到影响——而 IFS 就出现了这种情况。如果组织的不同部门没有朝着相同的目标努力，就会出现紧张局面。IFS 的典型特征是，开发、QA 和产品管理位于不同的组织部门，它们之间的互动变得僵化和官僚化，而不是流畅和协作。

When under pressures related to size and complexity, team dynamics and relationships often suffer—and this happened at IFS. There is always tension if different parts of the organization are not aligned on the same goals. IFS was typical in that development, QA, and product management were in different organizational units, and the interactions between them had become static and bureaucratic rather than fluid and collaborative.

组织内部存在着一种暗流，无论是纵向还是横向，尊重和信任都在减少。诸如“组织比以前更加分裂，相互指责的情况越来越多”和“信任参差不齐；我认为人们不会告诉我他们在想什么”这样的评论经常听到。有一种态度是“‘其他’群体表现不佳”。这是一种“我很好，但你不行”的态度。

There was an undercurrent, both vertically and horizontally within the organization, of decreasing respect and trust. Comments such as “The organization is more fractured than it used to be, with more finger pointing” and “Trust is mixed; I don’t think people tell me what they are thinking” were heard all too frequently. There was an attitude that “The ‘other’ groups are underperforming.” It was an “I’m OK but you’re not” attitude.

我们听到了如下的评论：

We heard comments such as the following:

“开发团队的生产力不够。”

“Development groups are not productive enough.”

“高层的 QA 和开发之间的关系一直不太好。”

“There has been a bad relationship between QA and development at a high level.”

“人们不信任开发中的产品管理，反之亦然。”

“There is a distrust of product management in development, and vice versa.”

“建筑团队只是把东西扔过墙给我们。”

“The architecture team just throws stuff over the wall to us.”

开发-QA-产品管理组织是功能孤岛——这也是使用瀑布生命周期的组织的典型特征。这三个领域的个人贡献者级别的员工通常不能很好地合作，决策往往会上报给层级中的经理，而不是在工作层面解决。

The development–QA–product management organizations were functional silos—again, typical of organizations using a waterfall life cycle. Staff at the individual contributor level in these three areas often didn’t work together well, and decisions tended to be escalated to managers in the hierarchies rather than be solved at the working level.

在 IFS，责任、义务和所有权属于职能部门，而不是团队。团队几乎没有决策权。“我们遇到了一个问题，需要 6 到 12 个人开几次会议——工作时间将近 30 个小时——才能在 15 分钟内做出修复决定。至少可以说，效率非常低下，”一位开发人员说。

At IFS, responsibility, accountability, and ownership resided in the functional departments, not the teams. The teams had little decision-making power. “We had one issue that came up which took several meetings of 6 to 12 people—nearly 30 hours of work—to make the decision on a 15-minute fix. Very inefficient, to say the least,” said one developer.

我们从管理层那里听说进度和质量很重要。但我们从工程人员那里听到了不同的说法：“进度在这里最重要。”人们觉得质量只是口头上说说而已。除了错误计数之外，几乎没有一致的质量定性或定量测量。性能测量强调进度。

We heard from management that schedule and quality were important. But we heard something different from the engineering staff: “Schedule is king around here.” People felt lip service was paid to quality. There was little consistent qualitative or quantitative measurement of quality other than bug counts. Performance measurements emphasized schedule.

软件市场对软件公司施加了巨大的压力，要求他们响应客户的功能要求并满足紧迫的时间表。这些市场压力迫使产品管理部门加强产品计划，以包含尽可能多的新功能，这使得开发部门陷入了总是拒绝这些计划的尴尬境地。对时间表和功能的关注取代了对质量的任何重视，增加了产品的技术债务，这反过来又使未来及时实现功能变得更加困难。随着发布日期的临近和现实的到来，匆忙添加的功能在没有充分测试的情况下被抛弃，导致工作和热情的损失。

The software marketplace places brutal pressure on software companies to respond to customer feature requests and meet tight schedules. These market pressures drive product management to beef up product plans to include as many new features as possible, putting development into the awkward position of always rejecting those plans. The focus on schedule and features drives out any emphasis on quality, raising the product’s technical debt, which in turn makes it more difficult to implement features in a timely manner in the future. As release dates approach and reality sets in, features hurriedly added without sufficient testing are jettisoned, resulting in lost work and lost enthusiasm.

IFS 的文化导致人们承诺执行超出其能力范围的计划，然后在最后放弃。“我能做”的态度导致功能无法实现。进度压力（感知或实际）的一个结果是人们专注于自己的优先事项，而不帮助其他团队。有这样的评论：“支持我们的小改动没有优先权。这种态度是，如果它不影响我的领域，那么我就无法帮助你。”

IFS’s culture led people to commit to a plan that exceeded their capacity and then bail out toward the end. A “can-do” attitude led to infeasible feature commits. One outcome of schedule pressure (perceived or actual) was people who focused on their own priorities and didn’t help other teams. There were comments such as “Minor changes to support us have no priority. The attitude is, if it doesn’t affect my area, then I can’t help you.”

瀑布式生命周期加剧了团队导向薄弱的问题，因为它鼓励了“把事情扔到隔壁下一个部门”的综合症。几个团队尝试了一种迭代开发形式，但缺乏培训和对迭代开发不熟悉导致了负面体验。

A waterfall life cycle exacerbated the weak team orientation because it encouraged a “throw it over the wall to the next department” syndrome. Several teams tried a form of iterative development, but lack of training and no familiarity with iterative development resulted in a negative experience.

Josh 和我向高层管理团队介绍了我们的评估结果和初步行动计划。他们接受了评估结果，并希望制定一项积极的行动计划。

Josh and I presented our assessment evaluation and a preliminary action plan to the senior management group. They accepted the assessment findings and wanted an aggressive action plan.

通常，公司采用的是“一次一个项目”的实施策略，即为一个项目团队（或几个团队）实施敏捷实践，然后从最初的团队中挑选经验丰富的实践者，组建新的团队。这种策略通常速度较慢，但​​风险较低。

Typically, companies used a project-at-a-time implementation strategy, which implemented agile practices for a project team (or a couple of teams) and then seeded new teams with experienced practitioners from the initial teams. This strategy was generally slower, but less risky.

然而，在 IFS 的案例中，采用全组织战略主要有两个原因。首先，整套产品是集成在一起并一起发布的。如果让一些团队进行迭代开发，而其他团队进行传统的瀑布式开发，协调起来会很困难。其次，IFS 领导希望整个组织都能感受到改进计划的一部分。逐个项目的战略会遗漏一些团队。

However, in IFS’s case, an organization-wide strategy was adopted for two main reasons. First, the entire suite of products was integrated and released together. Having some teams doing iterative development and others doing traditional waterfall development would have been difficult to coordinate. Second, IFS leaders wanted the entire organization to feel a part of the improvement initiative. A project-by-project strategy would leave out some teams.

要想取得成功，组织范围的战略需要高层管理人员的明显和持续支持。虽然项目逐项战略可以在有限的高层管理人员支持下取得成功（这确实有帮助），但组织范围的战略却不能。

To succeed, an organization-wide strategy requires visible and continuous support from top management. While a project-by-project strategy can succeed with limited top management support (which does help ), an organization-wide strategy cannot.

IFS 行动计划有两个目标：（1）加强团队和个人；（2）改进技术实践。加强团队和个人涉及团队结构：将结构修改为跨职能结构，改善团队之间的信任氛围，并让全体员工参与流程改进计划。

The IFS action plan had two objectives: (1) strengthen teams and individuals and (2) improve technical practices. Strengthening teams and individuals dealt with team structure: revising the structure to be cross-functional, improving the trust climate between groups, and involving the entire staff in the process improvement initiatives.

改进技术实践以我们称之为“精简敏捷”的实践为中心，其中“精简”表示并非所有实践都会在最初实施。实施团队由 IFS 员工和 Cutter 顾问组成，他们推荐了一套对 IFS 至关重要的项目管理、协作和技术实践。Josh 和我将我的 APM 方法与 XP 技术实践结合到这个“精简敏捷”方法论中。4^虽然我们担心推迟某些实践，但我们认为考虑到受众众多和实施时间紧迫，这是必要的。5 ^IFS的目标是始终尽可能保持接近可交付质量的代码——考虑到现有代码库的规模，这是一个艰巨的目标。

Improving technical practices centered on what we labeled “agile lite” practices, in which “lite” indicated not all practices would be implemented initially. The implementation team, consisting of IFS staff and Cutter consultants, recommended a set of project management, collaboration, and technical practices deemed critical to IFS. Josh and I combined my APM methods with XP technical practices into this “agile lite” methodology.⁴ Although we had concerns about delaying some practices, we thought it was necessary given the large audience and condensed time frame for implementation.⁵ IFS’s goal was to always stay as close to shippable quality code as possible—a daunting objective given the size of the existing code base.

4.我们在多项工作中都运用了这种方法。

4. We used this approach in several engagements.

5.将敏捷方法适应特定情况的过程对于持续成功至关重要。也就是说，适应还需要像 Josh 这样既了解各个方法又了解这些方法之间相互作用的人来协助适应。了解相互作用尤其重要。

5. This process of adapting an agile approach to a specific situation is essential to ongoing success. That said, adaptations also need someone, like Josh, who understands both the individual methods and the interactions among those methods to assist in the adaptations. Understanding the interactions is particularly critical.

在这次合作中，我设计了一个简单的指标来衡量进度，称为“缩短尾巴”。在瀑布式项目中，经常有一个称为代码冻结的时间，这意味着不再有新功能。代码冻结后包括错误修复、集成测试、文档和部署操作准备。对于为期一年的项目，从代码冻结到交付的时间可能是几个月、几个月，有时甚至是好几个月。敏捷团队的目标是将这段时间缩短到接近零。

During this engagement, I devised a simple metric to gauge progress, called “shortening the tail.” In a waterfall project, there was frequently a time called code-freeze, which meant no more new features. After the code-freeze would come bug fixes, integration testing, documentation, and operational readiness for deployment. On a one-year project, the time from code-freeze to ship might be months, several months, and sometimes many, many months. The goal of an agile team is to shorten that tail to near zero.

在 IFS，随着“尾期”的减少，好处显而易见：质量提高，士气提高，协作增加。公司成功的一个衡量标准发生在转型大约四个月后，当时一位营销经理向工程副总裁提出了紧急增强请求。产品团队临时派出了一个小团队来响应，新功能很快就部署了。在采用敏捷开发之前，这种响应很少见，营销经理对这种响应表示赞赏。

At IFS, as “tail-time” decreased, benefits became evident: Quality improved, morale improved, and collaboration increased. One measure of the company’s success occurred about four months into the transition, when a marketing manager came to the engineering vice president with an urgent enhancement request. The product team split off a temporary small team to respond and the new feature was deployed quickly. This type of response had been rare before agile development was adopted, and the marketing manager applauded the response.

Sciex 和 IFS 的敏捷实施截然不同。一种变革方法是逐个项目进行的，而另一种则是整个组织的。一种是对的，另一种是错的？一种比另一种更好吗？答案很模糊：成功取决于领导力、组织、信任、技术技能、协作、风险和不确定性等等。我们必须更加适应两者兼而有之的观点，而不是非此即彼的心态。话虽如此，我认为 Sciex 的成功比 IFS 的成就略高——不是因为整体战略，而是因为所有这些其他因素。当目标是在整个组织实施敏捷原则时，决定成功的因素不是使用这两种策略中的哪一种，而是高管和管理领导力。

THE AGILE IMPLEMENTATIONS at Sciex and IFS were quite different. One change approach was project-by-project, whereas the other was organization-wide. Was one right and the other wrong? Was one better than the other? The answer is murky: Success depends—on leadership, organization, trust, technical skills, collaboration, risk, and uncertainty, and much more. We must be more attuned to a both/and perspective rather than an either/or mindset. That said, I would rate our success at Sciex a little higher than our achievements at IFS—not because of the overall strategy, but because of the entirety of these other factors. When the goal is organization-wide implementation of agile principles, the deciding success factor isn’t which of these two tactics is used, but rather executive and management leadership.

在 IFS 项目以及本章中描述的其他客户体验之间，Josh 和我学到了很多东西。首先，虽然我们知道组织层面的转变与团队层面的转变不同，但我们了解了它们的不同之处。领导力更为重要：除了参与之外，领导者和团队都需要了解方法论和思维方式。我们必须学会以合理的成本在组织各个层面进行培训和指导。我们必须更好地设定和管理期望，因为高管希望在合理（或不合理）的时间范围内展示价值。我们了解了阻碍和障碍之间的区别（参见中国电信的故事）。我们了解到改变成功的衡量标准既必要又具有挑战性。从一次项目中学到了东西，我们将这些知识应用到下一次项目中。

Between the IFS engagement and the other client experiences described in this chapter, Josh and I learned a lot. First, while we knew that organization-level transitions were different from team-level ones, we learned how they were different. Leadership was much more important: In addition to involvement, both leaders and teams needed to understand the methodology and mindset. We had to learn how to train and coach at all organizational levels for a reasonable cost. We had to get better at setting and managing expectations, as executives wanted demonstrated value in a reasonable (or unreasonable) time frame. We learned the difference between impediments and barriers (see the Telecom China story). We learned that changing measures of success was both necessary and challenging. As we learned from one engagement, we applied those learnings to the next.

南方系统软件

Southern Systems Software

和 IFS 的故事一样，Barry 在 Southern Systems Software (SSS) 的故事也包括了几个项目的内容，反映了这段时期遇到的常见情况。我于 2008 年认识了 Barry，当时他是一家位于美国东南部的中型软件公司的软件开发总监。从我们第一次见面开始，我就能感受到他的热情。当我们谈论他的业务、他的组织和他的担忧时，出现了两个主要主题：他担心对客户的响应滞后，他担心公司软件的质量。

Like the IFS story, Barry’s story at Southern Systems Software (SSS) includes elements from several engagements reflecting common situations encountered during this period. I met Barry in 2008, when he was the director of software development for a mid-sized software company located in the southeastern United States. From the first time we met, I could sense his intensity. As we talked about his business, his organization, and his concerns, two main themes emerged: He was concerned about lagging responsiveness to customers, and he was concerned about the quality of the company’s software.

与当时许多软件公司的情况一样，SSS 的产品发布周期为一年。为了处理关键客户请求，它保留了一个单独的增强和维护小组，可以在正常发布周期之外实现新功能——但这种分散的运营导致了多个代码流，增加了质量问题。

As was the case with many software companies of the day, SSS’s product was on a one-year release cycle. To handle critical client requests, it maintained a separate enhancement and maintenance group that could implement new features outside the normal release cycle—but this fragmented operation contributed to multiple code streams that increased the quality problems.

“我感觉自己就像在跑步机上不停地转圈，”Barry 说道。“我们总是急于发布结束，测试永远没有足够的时间。在代码冻结前的最后一个月左右，开发人员急于将新功能添加到代码库中，他们越来越不关心质量。现在，我们将近一半的发布周期用于各种类型的测试和集成。除非是紧急情况，否则在发布的最后四个月内不会添加任何新内容——当然，有这么多时间，产品经理总是会遇到紧急情况。”

“I feel like I’m on a treadmill going round and round in circles,” said Barry. “We are always hurrying towards the end of a release and testing never has enough time. In the last month or so before code-freeze, developers are rushing to get new features into the code base, they are less and less concerned with quality. We now take up nearly half of our release cycle in various types of testing and integration. Nothing new gets added in the last four months of the release unless it’s an emergency—and, of course, with that much time, product managers are always coming up with emergencies.”

开发人员一直处于压力之下，看不到摆脱困境的出路。他们想编写高质量的代码；他们只是觉得时间压力太大了。“除了名字之外，我们对敏捷知之甚少”，这是开发人员 Nancy 的评论。她的想法与其他几位员工的想法一致：“任何东西都比我们现在拥有的更好，所以我愿意试一试！”

Developers were constantly stressed and couldn’t see the way out of the morass. They wanted to produce quality code; they just felt the time pressure was too great. “We don’t know much about agile except for the name” was a comment from Nancy, a developer. Her thoughts mirrored those of several other employees: “Anything is better than what we have now, so I’m willing to give it a go!”

这似乎是成功实现敏捷转型的完美场景，但事实并非如此。交付团队虽然举步维艰，但还是设法在接下来的一年里完成了部分转型。他们实施了敏捷实践，以两周为周期进行迭代，开始开发人员单元测试，进行每日站立会议，并让产品经理参加迭代规划会议。实施似乎进展顺利——但只是暂时的。

This seemed the perfect scenario for a successful agile transformation—but it wasn’t. The delivery teams struggled but managed to make a partial transition over the next year. They implemented agile practices, worked in two-week iterations, began developer unit testing, practiced daily stand-ups, and brought product managers into iteration planning meetings. The implementation seemed to go well—for a time.

但管理层却错失良机。例如，高管任命了一位以指挥控制倾向而闻名的经理作为敏捷倡导者，负责监督转型。包括总监在内的经理从未过渡到适应性管理风格。他们继续以传统方式衡量进度，继续以愿望为基础进行规划和微观管理。换句话说，虽然管理层支持转型，但他们自己从未接受敏捷。

But management missed the boat. For example, as the agile champion, the person who would oversee the transformation, executives appointed a manager known for his command-control tendencies. The managers, including the director, never made the transition to an adaptive management style. They continued to measure progress in traditional ways, continued their wish-based planning and their micromanaging. In other words, while management supported the transition, they never embraced agility themselves.

当 Josh 和我致力于更大规模的敏捷转型时，很明显我们的组织变革技能需要改进。

As Josh and I worked with larger agile transformations, it became clear our organizational change skill set needed improvement.

敏捷项目管理

Agile project management

随着勇敢的高管将敏捷实施扩展到企业，项目管理的重要性也随之增加。在与客户合作时，我和 Josh Kerievsky 使用了 XP/APM 组合方法。我们解决了当时流行的项目管理问题。敏捷项目领导力网络也考虑了这个问题，项目管理协会 (PMI) 也开始关注敏捷项目管理。我于 2004 年出版的《敏捷项目管理》第一版解决了这一问题，但到了 2009 年，是时候更新版本了。

As agile implementations were expanded into enterprises by courageous executives, project management increased in importance. With our clients, Josh Kerievsky and I used an XP/APM combination methodology. We addressed the type of project management question that was circling around in this period. The Agile Project Leadership Network pondered this question as well, and the Project Management Institute (PMI) began taking notice of agile project management. The first edition of my Agile Project Management book, released in 2004, addressed the type question, but in 2009 it was time for an updated version.

接下来的部分将介绍关键的项目管理主题（价值确定、约束、敏捷三角）和一个危险的敏捷趋势（发布计划的不幸消亡）。我想探究的一个关键问题是“如果变化、适应和灵活性是敏捷项目的标志，而符合计划是传统项目的标志，那么为什么我们仍然使用传统衡量标准来衡量敏捷项目的成功？”绩效衡量标准（在团队、产品/项目和组织层面）对于改变思维方式和方法至关重要。虽然本章涵盖了其他 APM 主题，但绩效衡量是主要关注点。

The next sections cover key project management topics (value determination, constraints, the Agile Triangle) and one dangerous agile trend (the unfortunate demise of release planning). One key question I wanted to pursue was “If change, adaptation, and flexibility are the trademarks of agile projects, and conforming to plan is the trademark of traditional projects, then why do we still measure success on agile projects using traditional measurements?” Performance measures—at the team, product/project, and organizational levels—are critical to changing mindsets and methodologies. While other APM topics are covered in this chapter, performance measurement is a primary focus.

在 2006 年的一次会议上，Paul Young (Sciex) 讲述了一个故事，讲的是内部开发人员为其营销部门开发的应用程序。根据之前的 IT 经验，营销部门列出了他们想要的 100 个功能。

DURING A 2006 conference, Paul Young (Sciex) presented a story about an application internal developers built for their marketing department. Based on prior experience with IT, the marketing department generated a list of 100 features that they wanted.

“很好，”保罗说。“你最喜欢的三件是什么？”

“Fine,” said Paul. “What are your top three?”

市场经理回答说：“100个都是必需的。”

“All 100 are really needed” was the marketing manager’s reply.

“我们明白，您将获得所有功能，但我们会在早期迭代中提供三个最高价值的功能，然后再逐步提供您的列表。”

“We understand, you will get all of the features, but we will deliver the three highest-value features in early iterations and then work down your list.”

在第一次演讲结束时，保罗再次提出了这个问题：“你的下一个前三名是什么？”

At the end of the first delivery, Paul asked the question again: “What are your next top three?”

市场经理似乎还没有完全理解这一流程。他再次要求提供其余 97 个功能。

It seemed the process hadn’t been fully understood by the marketing manager. He again asked for all of the remaining 97 features.

“正如我们所承诺的，我们将完成所有任务。现在我们只需要完成接下来的三项任务，”保罗说道。

“As we promised, we will do them all. We just need the next three now,” said Paul.

这个过程一次又一次地进行，直到大约 20 个功能被实现。Paul 再次问了“接下来的前三名”的问题。

This process proceeded iteration by iteration until about 20 features had been implemented. Paul asked the “next top three” question again.

“好吧，”营销经理说道，“你迄今提供的功能很有价值，我们已经在使用它们了。所以，现在，我们想暂停这个项目，并学习如何充分利用我们已有的功能。其他 80 个功能如果能有就好了，但我们可能用不到它们。”

“Well,” the marketing manager offered, “the features you have delivered to date are valuable and we are already using them. So, for now, we would like to hold up the project and learn to fully use what we have. The other 80 features would be somewhat nice to have, but we may not get to them.”

正如保罗向观众所说的，如果团队使用传统的瀑布式方法，那么所有 100 个功能都会被记录下来并交付。“我们还不如拿了钱点个篝火。采用敏捷方法的一大好处就是你不用做所有的事情！”

As Paul related to the audience, if the team had used a traditional waterfall approach, all 100 features would have been documented and delivered. “We might as well have taken the money and lit a bonfire. A big benefit from going agile is all the stuff you don’t do!”

保罗的故事激发了我对价值和成本之间关系的思考。在考虑价值获取时，敏捷经理需要检查项目交付的累计价值与产生的累计成本。然后可以提出问题，例如“我们是希望以 100% 的计划成本获得 100% 的计划价值，还是希望以 70% 的成本获得 90% 的价值？”由于敏捷开发在早期就提供了最高价值的功能，因此这种管理权衡变得合理，甚至势在必行。这种价值观也改变了我们对投资组合管理的看法。在一个项目中开发最后 10% 到 20% 的边际功能可能会延迟在下一个项目中获取更高的价值。显然，经理必须评估的不仅仅是开发成本，还有机会成本。

Paul’s story stimulated my thinking about the relationship between value and cost. In looking at value capture, agile managers need to examine cumulative value delivered versus cumulative cost incurred on a project. Then questions can be posed, such as “Do we want 100% of the planned value for 100% of the planned cost, or would we prefer stopping at 90% of the value for 70% of the cost?” Because agile development delivers the highest-value features early, this type of management trade-off becomes reasonable, even imperative. This view of value also changed how we think about portfolio management. Developing the last 10% to 20% of marginal functionality on one project may delay capturing the higher value on the next project. Clearly, managers must evaluate not just development cost, but also opportunity cost.

在 CIO 论坛演示期间展示了 70% 成本对应 90% 价值的图表后，一位参与者评论道：“我们是否会因为项目经理删除低价值功能和提前完成而给予奖励？我认为不会，但也许我们应该这样做。”

After showing a 90% value for 70% cost chart during a CIO forum presentation, one participant commented, “Do we reward our project managers for deleting low-value functionality and early completion? I think not, but maybe we should.”

2010 年，我到伦敦的 Thoughtworks 办公室咨询一位客户，并会见了正在与另一位客户合作的团队。在了解了他们的项目后，我问道：“那么，从你的角度来看，这似乎是一次成功的合作。客户的看法是什么？”

In 2010, I visited the Thoughtworks office in London to consult with a client and meet with a team engaged with another client. After learning about their project, I asked, “So, from your perspective, this appears to be a successful engagement. What is the client’s view?”

“客户似乎对我们目前的进展感到满意”他答复道。

“The client appears to be pleased with our progress so far” was the reply.

我的下一个问题是：“客户最关心的是什么？”

“What seems to be the client’s greatest concern?” was my next question.

“速度”是团队立即做出的反应。

“Velocity” was the instant response from the team.

“那您还报告了哪些其他指标呢？”我问道。

“And what other metrics do you report?” I queried.

“其实没有什么，只是速度。”

“None really, just velocity.”

速度⁶并不是衡量成功的标准。它可以帮助团队进行容量规划，但它是一种糟糕的绩效指标，可能会适得其反。看着墙上团队的故事卡，我建议，除了估计的故事点之外，他们还与客户的产品负责人合作分配价值点（只是相对的 1-5 评估）。在每次迭代结束时，他们可以报告他们已经交付了 35 个价值点，并花费了 25 个故事点。几个月后，当我跟进时，他们报告说客户喜欢价值点的想法，并且很少再抱怨速度。有时，绩效衡量标准的简单变化可能会产生深远的影响。

Velocity⁶ isn’t a measure of success. It can help a team with capacity planning, but it is a poor performance metric that can be counterproductive. Looking at the team’s story cards on the wall, I suggested that, in addition to the estimated story points, they work with their customer’s product leader to assign value points (just a relative 1–5 evaluation). At the end of each iteration, they could then report they had delivered 35 value points and expended 25 story points. When I followed up a few months later, they reported the customer liked the idea of value points and rarely complained about velocity anymore. Sometimes a simple change in performance measures can have a profound effect.

6.速度衡量每个时间段的故事点。故事点表示一项工作的相对大小（工作量）。

6. Velocity measures story points per time period. Story points represent the relative size (effort) of a piece of work.

在传统项目中，需要花费大量时间来计算项目成本和收益——从项目组合管理小组开始，以确定项目的优先顺序。这些计算往往基于对未来确定性的不可靠假设。基于故事点进行规划的一个好处是它们是相对的，而不是绝对的。如果未来不确定，为什么还要费心进行迅速过时但耗时的计算呢？同样的问题不也适用于收益或价值确定吗？正如伦敦团队使用价值点一样，它们非常有用，在大多数情况下比绝对数字更有用，而且只需付出最少的努力。

On traditional projects, serious time was spent calculating project costs and benefits—beginning with portfolio management groups for prioritizing projects. These calculation binges were often based on shaky assumptions about the certainty of the future. One benefit of planning based on story points is that they are relative, not absolute. If the future is uncertain, why bother with rapidly obsolete but time-consuming calculations? Wouldn’t the same question apply to benefit, or value, determination? As with the London teams’ use of value points, they can be incredibly useful, more so than absolute numbers in most cases, and consume minimal effort.

第 6 章深入探讨了质量困境，本章也对价值做了同样的探讨。现在是时候解决敏捷三角的最后一角“约束”了。

Chapter 6 delved into the quality quagmire, and this chapter has done the same for value. It’s now time to address “constraints” as the final corner of the Agile Triangle.

约束是护栏，是防止适应性行动范围超出预定限制的路标。它们为开发团队的决策提供了限制。此外，约束还能激发创新。

CONSTRAINTS ARE GUARDRAILS, guideposts that keep the range of adaptive actions from exceeding predetermined limits. They provide dev teams with limits to their decision making. Furthermore, constraints trigger innovation.

有一次度假，我参观了圣地亚哥的民艺国际博物馆。在博物馆馆长的带领下，我们参观了 20 世纪 30 年代中期的圣多明各普韦布洛（新墨西哥州）项链。“这条项链的有趣之处在于，”导演说，“黑色元素不是珊瑚，不是黑曜石，而是融化的旧留声机唱片。大萧条时期，美洲原住民艺术家因缺乏材料而受到限制。每个人都认为创造力和创新是由自由驱动的。但在艺术界，它们往往是由限制驱动的。”

Once on vacation, I visited the Mingei International Museum in San Diego. During a tour by the museum director, we were looking at a mid-1930s Santo Domingo Pueblo (New Mexico) necklace. “Interesting about this necklace,” the director said, “are the ‘nots’—not coral, not obsidian, but old melted phonograph records for the black element. During the Depression, the Native American artists were constrained by the lack of materials. Everyone thinks creativity and innovation are driven by freedom. In the art world, they are often driven, instead, by constraints.”

项目管理约束包括范围、进度和成本，它们是传统项目管理“铁三角”的组成部分。其中，进度被滥用得最厉害。与质量一样，时间比乍一看要复杂得多。

Project management constraints are scope, schedule, and cost—the components of the Iron Triangle of traditional project management. Of these, schedule has been abused the most. Like quality, time is more complex than it seems at first.

时间期限一直是软件开发项目中普遍存在的一个主题。但具体是什么时候？“延迟”的定义是什么？时间是最重要的控制指标吗？我能想到几个时间主题：计划时间与实际时间、已用时间、基准性能和周期时间。最后，我们应该如何使用时间——作为目标还是约束？

Time deadlines have been a pervasive theme in software development projects. But which time? What defines “late”? Is time the most important control metric? I can think of several time topics: planned versus actual, elapsed time, benchmark performance, and cycle time. Lastly, how should we use time—as an objective or a constraint?

项目经理强调计划时间与实际时间。制定计划是好的，不制定计划是坏的。在模糊需求（所有需求都是模糊的）、不一致的估计、未来的不确定性、政治以及无数其他因素的问题之间，显然计划时间与实际时间是一个复杂的话题。不幸的是，计划往往更多地与政治有关，而不是估计——我称之为基于愿望的计划。错过交付日期可能是管理层和软件开发之间不满和失去信誉的最大原因。

Project managers emphasize planned versus actual time. Making the plan is good; not making the plan is bad. Between the problems with fuzzy requirements (all requirements are fuzzy), inconsistent estimating, future uncertainty, politics, and a myriad of other factors, it’s clear planned versus actual time is a complex topic. Unfortunately, plans are often more about politics than estimates—I call them wish-based plans. Missed delivery dates are probably the greatest cause of dissatisfaction and loss of credibility between management and software development.

时间的第二个视角是时间流逝——从项目开始到结束的时间。当经理抱怨“项目延期”时，他们可能指的是项目耗时太长，与计划日期无关。无论如何，抱怨都会随着时间的推移而增加。例如，即使一个项目计划了两年，并且按计划进行，但由于总耗时太长，人们的看法往往是负面的。相比之下，一个在 3 到 6 个月内取得成果的项目可能被认为是成功的，无论计划如何。减少项目交付时间本身可以提高人们对成功的感受。

A second perspective on time is elapsed time—time from the beginning to the end of a project. When managers complain, “The project is late,” they may mean the project is taking too long, irrespective of the planned date. Complaints increase over time, regardless. For example, even though a project is planned for two years and is on schedule, the perception is often negative because of the overall length of time it is taking. By comparison, a project that delivers results in 3 to 6 months may be considered successful, regardless of plans. Reducing project delivery time can, by itself, improve the perception of success.

基准测试提供了关于时间的另一种视角，例如“我们如何比较？”我曾见过一些项目从计划与实际的角度被视为失败，即使与行业标准相比，它们的进度表现高于平均水平。如果产品团队收到的进度表根据行业或内部标准不合理，谁应该对日期负责？

Benchmarking provides another perspective on time, as in “How do we compare?” I’ve seen projects be considered failures from a plan-versus-actual perspective even though they had above-average schedule performance when compared to industry norms. If a product team receives an unreasonable schedule based on industry or internal norms, who should be accountable for dates?

持续交付 (CD) 技术让我们不禁要问，计划时间还是周期时间更重要。但哪个周期时间更重要呢？部署频率（几天、几周、每天x次）、功能周期时间（从待办事项发布到交付）或项目周期时间（从开始到结束）——所有这些都有其一席之地。

Continuous delivery (CD) technology causes us to ask whether schedule time or cycle time is more important. But which cycle time? Deployment frequency (days, weeks, x times per day), feature cycle time (release from backlog to delivery), or project cycle time (beginning to end)—all of these have a place.

在我早期的工作中，我经常说：“时间限制并不关乎时间，而关乎做出艰难的决定。”在短迭代和短项目中，艰难的决定往往来得早、来得频繁。

In my early work I often said, “Time-boxing is not about time; it is about making hard decisions.” With short iterations and short projects, hard decisions come early and often.

当时间成为制约因素时，它迫使人们做出艰难的决定。瀑布式方法倾向于将问题推到后面，最终落在瀑布底部的可怜人身上——测试人员。瀑布早期的员工保持“按计划”工作，因为他们宣布文档已完成。因此，在计划“结束”时，分配给测试的时间从六个月缩短到三周。您可以伪造需求文档的完成情况，但您无法伪造经过测试的运行代码。

When time functions as a constraint, it forces hard decisions. Waterfall methodologies tended to kick the can down the road, where it eventually landed by the dumpster load on the poor souls at the bottom of the waterfall—the testers. Staff earlier in the waterfall stayed “on schedule” because they declared documents done. So, near the “end” of the schedule, time allocated to testing shrank from six months to three weeks. You can fake the completion of a requirements document, but you can’t fake tested, running code.

在编写《敏捷项目管理》第二版时，我的主要目标之一是讨论绩效衡量问题，并引入敏捷三角（见图7.1）来替代传统项目管理中使用的铁三角。我听到敏捷团队抱怨：“管理层希望我们敏捷且适应性强，但我们还必须遵守项目的计划范围、进度和成本目标。”管理层似乎想要敏捷，但采用传统的绩效衡量标准。如果适应性和灵活性是敏捷项目的标志，而遵守计划是传统项目的标志，那么为什么我们仍然使用相同的传统框架来衡量敏捷项目的成功？如果敏捷领导者专注于成功适应不可避免的变化，而不是遵循计划并进行最小的更改，那么通过严格遵守范围、进度和成本计划来衡量成功将是行不通的。因此，我创建了敏捷三角，如图 7.1所示。其维度如下：

ONE OF MY PRIMARY goals when writing the second edition of Agile Project Management was to discuss performance measurement issues and introduce the Agile Triangle (see Figure 7.1) as a replacement for the Iron Triangle used in traditional project management. I heard agile teams complain, “Management wants us to be agile and adaptive, but we also must conform to the project’s planned scope, schedule, and cost objectives.” Management, it seemed, wanted agility, but with traditional performance measures. If adaptation and flexibility are the trademarks of agile projects and conforming to the plan is the trademark of traditional projects, then why do we still measure success on agile projects using the same traditional framework? If an agile leader focuses on adapting successfully to inevitable changes rather than following the plan with minimal changes, then measuring success by strictly adhering to a scope, schedule, and cost plan would be dysfunctional. So, I created the Agile Triangle, shown in Figure 7.1. Its dimensions are as follows:

• 价值目标：向客户提供有价值的产品

• Value goal: deliver a product of value to the customer

• 质量目标：打造可靠、适应性强的产品

• Quality goal: build a reliable, adaptable product

• 约束目标：在可接受的约束条件下实现价值和质量

• Constraint goal: achieve value and quality within acceptable constraints

自2009 年《敏捷项目管理》出版以来，我一直致力于企业数字化转型，并对敏捷三角做了一些修改。首先，我用“客户”替换了描述性短语“可发布产品”，其次，我从短语“可靠、适应性强的产品”中删除了“产品”。我认为这些微小的变化将其适用性扩展到组织单位以及产品、服务和项目。任何类型的计划（在第 8 章中，“计划”将用于精益价值树的行动层面）都可以通过其对客户价值和质量（可持续性）的影响进行评估，同时保持在既定的界限（约束）内。

Since Agile Project Management was published in 2009, I’ve worked on enterprise digital transformations and made a couple of modifications to the Agile Triangle. First, I replaced the descriptive phrase “releasable product” with “customer,” and second, I removed “product” from the phrase “reliable, adaptable product.” I think these minor changes extend its applicability to organizational units, as well as products, services, and projects. Initiatives of any kind (in Chapter 8, “initiatives” will be used at the action level of a Lean Value Tree) can be evaluated by their impact on customer value and quality (sustainability), while remaining within the established boundaries (constraints).

衡量成功是个棘手的问题。摩托罗拉 20 世纪 90 年代耗资数十亿美元的卫星铱星项目注定会失败，在市场上一败涂地。同时，电影《泰坦尼克号》严重超出预算和进度，早期评论家认为它是一部 2 亿美元的惨败，但它是第一部全球票房收入超过 10 亿美元的电影。按照铁三角项目管理的成功衡量标准（范围、成本和进度），《泰坦尼克号》是失败的。在某些圈子里，铱星被认为是成功的，因为它在成本和进度计划内满足了原始规格。使用敏捷三角，泰坦尼克号项目将被视为成功——即使超出了限制，它仍然创造了价值。铱星将被视为失败，因为它未能创造价值，尽管按照传统的项目衡量标准，它是成功的。

Measuring success is tricky. Motorola’s 1990s ill-fated, multibillion-dollar, satellite-based Iridium project was a spectacular failure in the market. Meanwhile, the movie Titanic, which was severely over budget and schedule—and viewed by early pundits as a $200 million flop—was the first movie to generate more than $1 billion in worldwide revenue. By Iron Triangle project management measures of success—scope, cost, and schedule—Titanic was a failure. Within some circles, Iridium was considered a success because it fulfilled the original specifications within the cost and schedule plans. Using the Agile Triangle, the Titanic project would be considered a success—it delivered value even though it exceeded its constraints. Iridium would have been considered a failure because it failed to deliver value, even though according to traditional project measurements, it succeeded.

在铱星项目中，铁三角导致了错综复杂的责任制。工程师可以说，“我们按照你的要求建造”，而产品经理们抱怨道：“但这不是我们今天需要的。你们提供的是我们两年前认为需要的。”没有什么比 Cutter Consortium 的同事 Helen Pukszta 的以下言论更能凸显这个问题了。这句话总是让我震惊，但不幸的是，这在传统的 IT 组织中却是常态。

In the Iridium project, the Iron Triangle enabled tangled accountability. The engineers could say, “We built what you told us to build,” while product managers complained, “But it isn’t what we need today. You provided what we thought we needed two years ago.” Nothing highlights this problem more than the following quote from colleague Helen Pukszta at the Cutter Consortium. The quote always stunned me, but unfortunately was normal practice in traditional IT organizations.

对我关于成功衡量标准的思考影响很大的人是我的朋友兼同事 Rob Austin，他提出了截然不同的衡量标准观点。Rob的著作《组织绩效衡量与管理》 （Austin，1996 年）的精髓就描述了“大多数衡量系统注定要失败”。Rob 是位于安大略省伦敦的西安大略大学理查德艾维商学院的教授，曾任哈佛商学院副教授。

A person who greatly influenced my thinking about measures of success is my friend and colleague Rob Austin, who provided a quite different view of measurement. Most measurement systems are doomed to failure describes the essence of Rob’s book Measuring and Managing Performance in Organizations (Austin, 1996). Rob is a professor at the Richard Ivey School of Business at the University of Western Ontario, located in London, Ontario, and formerly an associate professor at Harvard Business School.

您必须改变成功的衡量标准才能实现敏捷开发的成功。

You have to change measures of success to succeed with agile development.

Rob 的组织绩效模型预测了为什么许多测量程序会失败。基于经济理论，他建立了一个令人信服的模型，解释了通过测量激励员工的困难，尤其是在知识型工作中。他将测量功能障碍定义为测量某物以获得特定结果，但测量结果却导致完全相反的反应。正如 Rob 所表明的那样，在复杂情况下依赖简单的测量几乎总是会导致功能障碍。

Rob’s organizational performance model predicts why so many measurement programs fail. Based on economic theory, he builds a convincing model of the difficulties in motivating through measuring, particularly in knowledge work. He defines measurement dysfunction as measuring something to get a particular result in which the measurement causes exactly the opposite response. As Rob shows, reliance on simple measurements in complex situations nearly always leads to dysfunction.

约束仍然是至关重要的项目衡量标准，但它们不是项目的目标。价值是目标，随着项目的推进，约束可能需要调整以增加客户价值。进度可能仍然是一个固定的约束，但随后会调整价值以在进度约束内交付。如果我们想要适应性，我们必须奖励它。调整约束以满足价值或质量目标有助于组织满足这一需求。

Constraints are still vital project measures, but they are not the project’s goal. Value is the goal, and constraints may need to be adjusted as the project moves forward to increase customer value. Schedule might still be a fixed constraint, but then value is adjusted to deliver within the schedule constraints. If we want adaptability, we must reward it. Adjusting constraints to meet value or quality goals helps organizations meet this need.

我曾与一家组织合作，使用交付日期和文档完整性来衡量产品经理的绩效。此外，由于在年度产品发布周期中，一旦产品经理完成了第 2 版的要求，他们就必须立即转向第 3 版，没有时间与开发人员协作。这些以及其他绩效指标都必须改变，任何敏捷实施才能成功。

One organization I worked with used delivery date and document completeness to measure product managers’ performance. Furthermore, because of the yearly product release cycle, once the product managers completed requirements for Release 2, they had to immediately move on to Release 3—leaving no time to collaborate with the development staff. These, and other performance metrics, had to change before any agile implementation could be successful.

在 2000 年代中期，PMI 代表了一种传统的项目管理方法。随着 APM 越来越受欢迎，我在美国各地的 PMI 分会发表演讲。我提出了一套与铁三角相关的标准问题。铁三角旨在说明三个组成部分之间的权衡，但即使是“铁”这个名字也与这种解释相矛盾，并导致管理者认为这三个组成部分都是固定的。

In the mid-2000s, PMI represented a traditional approach to project management. As APM was becoming more popular, I spoke at local PMI chapters around the United States. I had a standard set of questions related to the Iron Triangle. The Iron Triangle was intended to illustrate the trade-offs among three components, but even the name “Iron” contradicts that interpretation and leads managers to view all three as fixed.

“你们的项目有不同特点吗？”我问道。“例如，一个项目可能是办公室搬迁项目，需要一组易于定义的有序任务；另一个项目可能是人工智能项目，创新是重中之重？”

“Do you have projects with different profiles?” I asked. “For example, one might be an office move project for which you need a sequenced set of tasks that are easily definable, and another might be, say, an artificial intelligence project for which innovation is paramount?”

“当然，”他们会回答。

“Of course,” they would answer.

我想问下一个问题：“它们是非常不同类型的项目吗？”

I would ask the next question: “Are they very different kinds of projects?”

“当然。”

“Of course.”

“您是否使用相同的成功衡量标准——范围、进度、成本？”

“And do you use the same measures of success—scope, schedule, cost?”

你可以看到灯亮了。答案仍然是“是”——但更加犹豫。他们可以看到我让他们陷入的难题。范围是一种约束，而不是目标。

And you could see the lights coming on. The answers were still “Yes”—but a much more hesitant “Yes.” They could see the conundrum I’d led them into. Scope is a constraint, not an objective.

最近，在拜访一位新医生时，我花了很多时间跟他交谈，而他则在笔记本电脑上不停地敲打。还记得（不久前）医生觉得在键盘上输入数据很不体面吗？想想那些试图构建第一个医患应用程序和交互的可怜软件开发人员。您认为范围、进度和成本应该是关键的绩效目标吗？

During a recent visit to a new doctor, I spent lots of time talking to the top of his head as he banged away on his laptop. Remember (not too long ago) when doctors felt entering data on a keyboard was beneath them? Think of the poor software developers trying to build the first doctor/patient applications and interactions. Do you think scope, schedule, and cost should have been the key performance objectives?

在第二个敏捷时代，人们对​​敏捷项目管理、项目经理是否必要以及其他话题进行了大量讨论。成熟的敏捷组织意识到项目管理仍然是高效团队的关键方面，并知道他们应该专注于敏捷的项目管理风格。他们意识到优秀的项目经理可以成为大规模转型的有效催化剂，因为他们可以在治理、组织、绩效衡量和流程等领域成为敏捷团队和管理层之间的桥梁。

During this second Agile-era period, there was considerable discussion about agile project management, whether project managers were necessary, and other topics. Maturing agile organizations realized project management was still a critical aspect of effective teams, and knew they should focus on an agile style of project management. They realized good project managers could be effective catalysts of large-scale transformations because they could be a bridge between agile teams and management in areas such as governance, organization, performance measures, and process.

Pat Reed 和我与其他人合作推出了 PMI 敏捷实践社区，以便为 PMI 成员提供敏捷知识和技能。Thoughtworks 在 2009 年芝加哥敏捷联盟会议期间举办了发布会。PMI 利用这个实践社区开发了其敏捷项目管理认证计划（2011 年）。2012 年，PMI 推出了这项认证计划，第一年就拥有近 3,000 名证书持有者。如今，PMI 提供四项敏捷项目管理认证，2021 年发布的第七版 PMBoK 包含了重要的敏捷内容。

Pat Reed and I worked, with others, on the launch of PMI’s Agile Community of Practice to equip PMI members with agile knowledge and skills. Thoughtworks hosted the launch party during the 2009 Agile Alliance conference in Chicago. PMI drew on this Community of Practice to develop its Agile Project Management certification program (2011). In 2012, PMI launched this certification program, which had nearly 3,000 certificate holders in the first year. Today PMI offers four Agile Project Management certifications and the seventh release of the PMBoK in 2021 included significant agile content.

当我们进行更大规模的敏捷转型时（例如综合财务软件和中国电信（我们将很快访问）），引入敏捷三角来取代传统的项目管理铁三角具有重要意义。

The introduction of the Agile Triangle to replace the traditional Iron Triangle of project management was significant as we approached larger agile transformations such as those at Integrated Financial Software and Telecom China (which we will visit shortly).

从一开始，我对敏捷方法论的担忧之一就是对传统规划问题反应过度。传统主义者陷入了过于详细、确定性的计划中，而许多敏捷主义者则完全忘记了规划。

ONE OF MY CONCERNS about agile methodologies, from the beginning, was an overreaction to the problems with traditional planning. While traditionalists got bogged down in their overly detailed, deterministic plans, many agilists forgot about planning completely.

2004 年，我在撰写《敏捷项目管理( APM )》时，担心敏捷团队过于专注于每隔一到两周交付一次故事，而长期的产品和技术目标被抛在一边。APM用整整一章来讲述发布计划——为项目或产品制定目标、约束和指导方针。我最近问 Mike Cohn 7 ^，他正在合作的团队/组织中（2022 年）有多少人制定了发布计划。他的回答是“几乎没有。”他同意这种专注于每周、每天、每小时功能交付的激光趋势是一种有害的趋势。

At the time I wrote Agile Project Management (APM) in 2004, I was concerned agile teams were so focused on delivering stories every one to two weeks that longer-term product and technical goals were getting swept aside. APM devoted an entire chapter to release planning—laying out goals, constraints, and guidelines for the project or product. I asked Mike Cohn⁷ recently how many of the teams/organizations he was working with (in 2022) did release planning. His answer, “Virtually none.” He agreed this laser focus on weekly, daily, hourly feature delivery was a damaging trend.

7.迈克·科恩 (Mike Cohn) 是另一位后宣言敏捷先驱，为该领域做出了非凡的贡献。

7. Mike Cohn is another post–Manifesto Agile pioneer who made extraordinary contributions to the field.

您可能会认为，传统管理过度规划导致了敏捷反​​应——规划不足。“规划”和“项目管理”这两个词对敏捷主义者来说简直是天方夜谭。但许多人宁愿放弃这些术语，而不是重新定义它们。敏捷规划应该以结果为导向——价值和目标。还记得我分享的有关 Alias Systems 的故事吗？我们根据实时反馈调整了发布规划和迭代规划结果。团队在两周的迭代中交付产品，但始终牢记产品愿景、功能优先级和时间限制。他们同时坚持短期和长期目标，平衡两者。

You might argue traditional management over-planning ushered in the agile reaction of under-planning. The very words “planning” and “project management” became anathemas to agilists. But rather than redefine those terms, many preferred to abandon them. Agile planning should be outcome oriented—value and goals. Remember the story I shared about Alias Systems? We adapted the release planning and iteration planning outcomes based on real-time feedback. The team delivered in two-week iterations, but always had their product vision, feature priority, and time constraints in mind. They held onto their short-term and long-term goals concurrently, balancing the two.

个人和团队往往过于专注于较短的迭代，而忘记了全局。他们变得如此厌恶“规划”这个词，以至于放弃了未来，放弃了项目或产品的整体价值主张。这就是我喜欢“推测”和“设想”这两个词的原因——它们向团队传达了一种使命感，一种方向，而不是一个规定性的计划。

Too often individuals and teams concentrate so hard on shorter iterations that they forget the big picture. They have become so averse to the word “planning” they abandon the future, the overall value proposition for the project or product. This is the reason I like the terms “speculate” and “envision”—they convey a sense of purpose to a team, a direction rather than a prescriptive plan.

DevOps 的实践（持续集成和持续部署）为企业带来了可观的收益和价值，但其缺点是导致微观关注。当开发人员可以每天交付 10 次新功能时，下一个问题是他们是否应该这样做？

The practices of DevOps—continuous integration and continuous deployment—have contributed considerable benefits and value to businesses, but the downside is their contribution to micro-focusing. When developers can deliver new features 10 times a day, the next question is should they?

没有发布计划的团队在迭代规划中经常会摇摆不定，因为他们缺乏此类计划所提供的总体主题和背景。将摇摆不定与迭代区分开来并不总是那么容易，但这是优秀的产品所有者、项目经理、迭代经理和团队需要培养的技能。

Teams without release plans often oscillate in iteration planning because they lack the overall theme and context such a plan provides. Separating oscillation from iteration isn’t always easy, but it’s a skill good product owners, project managers, iterations managers, and teams need to cultivate.

组织变革

Organizational change

随着“流氓团队”时期逐渐过渡到“勇敢的高管”时期，敏捷专家需要获得或完善另一套技能，即组织变革管理技能。让小团队使用敏捷开发所需的实践以及让整个 IT 组织（更不用说整个企业）采用敏捷所需的实践要复杂得多。我们是从上到下实施，还是从下到上实施？我们是从几个团队开始，利用他们的经验来培育其他团队，还是“逐一”地^向所有人推广？我们将敏捷向上（组织层级）和横向（其他部门、其他分部）推进的策略是什么？我们如何灌输敏捷和实施敏捷？我们使用谁的变革模型和方法？

As the Rogue Teams period drifted into the Courageous Executives one, agilists needed to acquire or refine another set of skills—those of organizational change management. The practices necessary to get a small team to use agile development and those necessary to get an entire IT organization (much less an entire enterprise) to embrace agility are vastly more complicated. Do we implement from top to bottom, or from bottom to top? Do we start with a few teams and use their experience to seed others, or do we “sheep dip”⁸ everyone? What is our strategy for moving agility up (the organizational hierarchy) and sideways (other departments, other divisions)? How do we instill both being agile and doing agile? Whose change model and approach do we use?

8. “Sheep dip” 这个术语起源于 20 世纪 80 年代，用于对一两个研讨会中的每个人进行“浸入”，然后宣布他们现在已“结构化” - 类似于敏捷时代的两天“浸入”以成为 Scrum 熟练者。

8. “Sheep dip” was a term that originated in the 1980s and was applied to “dipping” everyone in a workshop or two and then declaring that they were now “structured”—akin to the Agile era’s two-day “dip” to become a Scrum proficient.

对于大多数早期的敏捷主义者来说，变革管理在我们的技能清单中处于中等位置，我的情况也是如此。我和我的同事都不是变革管理领域的专家，所以我们阅读了其他人的意见，借鉴了我​​们以前的经验，并设法应付过去。我结合使用了两种方法来与客户进行变革管理。

For most early agilists, change management was midway down on our skills list, and such was the case for me. My colleagues and I were not experts in the change management field, so we read what others had to say, worked from our prior experience, and managed to muddle through. I used a combination of two approaches to change management with clients.

杰瑞·温伯格是变革管理的早期思想家。在 20 世纪 90 年代中期的顾问营研讨会上，他向大家介绍了弗吉尼亚·萨提尔的变革模型，如图 7.2所示（Smith，2000 年）。我喜欢这个模型，因为它强调了一些关键点：

JERRY WEINBERG WAS an early thinker about change management. During Consultants’ Camp workshops in the mid-1990s, he introduced the group to Virginia Satir’s Change Model, shown in Figure 7.2 (Smith, 2000). I liked this model because it emphasized some key points:

• 情况在好转之前会先变得更糟（这对管理层来说是一个难以实现的认识，特别是如果这种改变被当作一种快速的万能药）。

• Things get worse before they get better (this is a difficult realization for management, particularly if the change was sold as a quick cure-all).

• 如果改变太不舒服，人们可能会放弃。

• People may give up on a change if it gets too uncomfortable.

• 从当前表现到更好表现的道路充满坎坷。

• The ride from current performance to better performance is bumpy.

• 成功的转型需要时间和金钱的投入。

• Successful transitions require investments in both time and money.

• 需要信任和理解来克服恐惧和抵抗。

• Trust and understanding are needed to overcome fear and resistance.

在一位客户的办公室，乔希和我一天早上走进经理区，发现周围到处都是气球。当被问及这是为什么时，经理说：“我们在庆祝混乱。”变革管理已经成为一个独立的行业。我相信如今有更复杂的方法，但我发现 Satir 模型既有用又易于解释。

At one client’s office, Josh and I walked into a manager’s area one morning to discover balloons flying around. When asked what the occasion was, the manager declared, “We are celebrating chaos.” Change management has become an industry on its own. I’m sure there are more sophisticated approaches today, but I found the Satir model both useful and simple to explain.

作为一名咨询师，我竭尽全力通过应用新方法、新方法论和新思维来帮助客户提高绩效，我最常用的参考资料是杰里·温伯格 (1985) 的《咨询的秘密》一书。在这本书首次出版近 40 年后，他的建议至今仍然具有现实意义。那些试图改变人类行为，尤其是思维方式的人，将从杰里的警告中受益：

As a consultant trying my best to assist clients in improving performance by applying new methods, methodologies, and mindsets, my go-to reference has been Jerry Weinberg’s (1985) book The Secrets of Consulting. His advice remains relevant today, nearly 40 years after the book’s first publication. Those who attempt to change human behavior, especially mindsets, would benefit from Jerry’s cautions:

永远不要承诺超过 10% 的改进^。9

Never promise more than ten percent improvement.⁹

9.Weinberg，1986，第6页。

9. Weinberg, 1986, p. 6.

大多数时候，对于世界上的大多数人来说，无论人们多么努力，都不会发生任何重大的事情^。10

Most of the time, for most of the world, no matter how hard people work at it, nothing of significance happens.¹⁰

10.Weinberg，1986，第 13 页。

10. Weinberg, 1986, p. 13.

在当今不断改变、改变、再改变的竞争中，我们有时会忘记我们正在与人打交道，而且我们所有人的改变都比我们想象的要慢。在与客户接洽之前，或者当现有接洽陷入困境时，我会在脑海中反复思考杰里的警告，并不断重复“耐心”的咒语。回顾敏捷时代的起源，我花了五年多的时间才从结构化方法过渡到自适应软件开发。今天，随着有关敏捷开发的材料和咨询的大量涌现，转变应该会更快，但它仍然远非瞬间完成。

In today’s race to change, change, change, we sometimes forget we are dealing with people, and we are all slower to change than we think. Before a client engagement, or when an existing engagement bogs down, I run Jerry’s cautions through my head and repeat the mantra “Patience.” Looking back at the Roots of Agile era, it took me more than five years to make my own transition from structured methods to adaptive software development. Today, with the avalanche of material and consulting on agile development, the transition should be quicker, but it remains far from instantaneous.

阿利斯泰尔·科克伯恩 (ALISTAIR COCKBURN) 将 Shu-Ha-Ri 聆听或学习模型引入当今的敏捷社区，该模型可追溯到近四个世纪前的日本能剧，并在其咨询实践中广泛使用。阿利斯泰尔的观点是，我们需要先了解人们的学习方式，然后才能了解如何管理变革。多年来，萨提亚和 Shu-Ha-Ri 帮助我完成了转型工作。

ALISTAIR COCKBURN INTRODUCED the Shu-Ha-Ri listening or learning model, dating to Japanese Noh theater almost four centuries ago, to the agile community today and has used this extensively in his consulting practice. Alister’s point was we needed to understand how people learn before we can understand how to manage change. Satir and Shu-Ha-Ri helped me through transformation efforts for a number of years.

阿利斯泰尔是一位伟大的作家，因此我不会试图解释他的作品，而是引用他早期的文章：¹¹

Alistair is a great writer, so rather than try to paraphrase his work, I’ll just quote his early article:¹¹

11.在www.heartofagile.com网站上可以找到 Alistair 原文的 PDF 版本。

11. A PDF of Alistair’s original article can be found on www.heartofagile.com site.

• “学习和掌握新技能的人会经历三个截然不同的行为阶段：跟随、分离和流利。处于跟随（熟）阶段的人会寻找一种有效的程序。即使十种程序都有效，他们也不能一次学会十种。他们需要先学习一种有效的程序。他们模仿它；他们学习它。”

• “People who are learning and mastering new skills pass through three quite different stages of behavior: following, detaching, and fluent. People in the following (Shu) stage look for one procedure that works. Even if ten procedures could work, they can’t learn ten at once. They need one to learn first, one that works. They copy it; they learn it.”

• “在分离阶段，即第二级阶段，人们会找出单一程序的局限性，并寻找程序何时失效的规则。他们实际上处于新学习的第一阶段，即学习程序的局限性。处于分离阶段的人会学会根据不同的情况调整程序。”

• “In the detaching, or Level 2, stage, people locate the limitations of the single procedure and look for rules about when the procedure breaks down. They are actually in the first stage of a new learning—namely, learning the limits of the procedure. The person in the detaching stage learns to adapt the procedure to varying circumstances.”

• “在第三个流畅阶段，对于从业者来说，她是否遵循某种特定技术变得无关紧要。她的知识已融入了上千种想法和行动中。问她是否遵循了某种特定程序，她可能会耸耸肩：对她来说，她是遵循程序、即兴发挥还是发明新程序并不重要。她了解期望的最终效果，只需朝着那个目标努力即可。”

• “In the third, fluent stage, it becomes irrelevant to the practitioner whether she is following any particular technique or not. Her knowledge has become integrated throughout a thousand thoughts and actions. Ask her if she is following a particular procedure, and she is likely to shrug her shoulders: It doesn’t matter to her whether she is following a procedure, improvising around one, or making up a new one. She understands the desired end effect and simply makes her way to that end.”

困扰我的一个问题是“规范敏捷性”这个矛盾的说法。公司抓住 XP 的 12 项实践或 Scrum 的 6 项实践，宣称自己是敏捷的。我使用“规范敏捷性”一词来描述组织倾向于将一组敏捷实践规定为强制性的倾向，而不是“适应性敏捷性”，其中敏捷实践不断适应每种情况。使用规范方法构建适应性软件有多大意义？

ONE ISSUE THAT bothers me can be identified by the oxymoron, “prescriptive agility.” Companies latch on to 12 practices of XP or 6 practices of Scrum and declare they are agile. I’ve used the term “prescriptive agility” to describe an organization’s tendency to prescribe a set of agile practices as mandatory, rather than “adaptive agility” in which agile practices are continually adapted to each situation. How much sense does it make to build adaptable software using a prescriptive methodology?

也许在学习敏捷实践时开处方是有意义的（Alistair 的“Shu”级别），但如果您不迅速转向适应性敏捷（这个形容词应该没有必要），您还不如使用传统方法。如果您没有在整个组织中分散冒险、不墨守成规、适应性强的人，您将无法实现敏捷。如果您还没有准备好接受混乱（在 Satir 模型中）并克服焦虑，您可能正在做敏捷，但您并没有敏捷。

Maybe prescribing agile practices makes sense while learning them (Alistair’s “Shu” level), but if you don’t move quickly to adaptive agility (the adjective should not be necessary) you might as well be using a traditional methodology. If you haven’t scattered adventurous, nonconformist, adaptive people throughout your organization, you will not achieve agility. If you are not ready to embrace chaos (in the Satir model) and work through anxiety, you may be doing agile, but you are not being agile.

Alistair Cockburn 已经通过定义他的“敏捷之心”解决了这个问题，它只有四个组成部分：协作、交付、反思和改进。这个“心”肯定更多的是心态而不是方法论。拥抱敏捷需要耐心、决心和勇气。这并不容易，但这正是拥抱敏捷本质所需要的^。12

Alistair Cockburn has addressed this issue by defining his “heart of agile,” which has only four components: collaborate, deliver, reflect, and improve. This “heart” is definitely more mindset than methodology. Embracing agility takes patience, determination, and courage. It’s not easy, but that’s what it takes to embrace the essence of agility.¹²

12.哪些行为体现了敏捷性？请继续阅读第 9 章。

12. What actions define an agile person? Read on to Chapter 9.

软件开发

Software development

首先是 Kent Beck (2000) 的《极限编程解析》和我的《自适应软件开发》（也是在 2000 年出版），这两本书引发了敏捷书籍的洪流。到敏捷时代的第二个十年，出现了 100 本最佳敏捷书籍，甚至 100 本最佳 Scrum 书籍。其他作者推广了看板、持续集成、DevOps、精益、敏捷项目管理、扩展敏捷等进步。这些进步激发了敏捷运动。

First, there were Kent Beck’s (2000) eXtreme Programming Explained and my Adaptive Software Development (also released in 2000), which started a flood of agile books. By the second decade of the Agile era, there were lists of the 100 best agile books and even the 100 best Scrum books. Other authors promoted advances such as Kanban, continuous integration, DevOps, Lean, agile project management, scaling agile, and much more. These advances invigorated the agile movement.

此时还有另外两个因素影响着敏捷实施——一个是技术因素，另一个是组织因素。

Two other factors were impacting agile implementations at this time—one technical and the other organizational.

改变组织而不是团队带来了层层困难。我开始注意到 IT 部门出现了分裂：一个小组负责内部、遗留的后台系统，另一个快速发展的小组负责网络和移动设备应用程序，有时也称为前台或客户互动应用程序。前者坚持使用 Monumental 方法论，而后者则越来越多地采用敏捷开发。怨恨情绪日益增长，因为互联网小组开始研究很酷的新事物，因此需要一种设想-探索的心态，而内部小组往往挣扎着将 80% 到 90% 的精力用于遗留系统的维护和小幅改进。传统方法和敏捷方法之间更广泛的市场竞争也发生在企业内部。

Transforming organizations rather than teams brought layers of difficulty. I began noticing a split in IT departments: One group was responsible for internal, legacy back-office systems, and a second rapidly growing group was responsible for web and mobile device applications, sometimes referred to as front-office or customer-engagement applications. The former stuck with Monumental Methodologies, while the latter increasingly embraced agile development. Resentment grew because the Internet groups got to work on cool new things, and therefore needed an envision–explore mindset, whereas the internal groups often struggled with 80% to 90% of their efforts going to legacy system maintenance and minor enhancements. The wider marketplace battle between traditional and agile methods took place inside enterprises as well.

一个结果是团队之间产生怨恨，另一个结果是发生冲突。互联网应用程序需要访问和更新遗留系统。遗留系统团队收到来自互联网团队的协助请求，由于敏捷团队的交付周期为一到两周，而遗留系统的发布周期长达数月，因此随之而来的响应时间冲突加剧了问题。一个组织，两种冲突的思维方式。几家大型咨询和研究公司提出了一种仅仅反映现状的解决方案：双模或双速 IT。双模 IT 不但没有解决问题，反而巩固了分裂。双模通常是事实上出现的结构，但它最适合作为一种过渡策略。

Resentment between the groups was one result; clashing was another. Internet applications required accessing and updating legacy systems. Legacy groups received requests for assistance from the Internet groups, and since the agile groups were on a one- to two-week delivery cycle and the legacy groups were on months-long release cycles, the ensuing response-time clash added to the problems. One organization, two clashing mindsets. A couple of large consulting and research firms proposed a solution that merely mirrored the status quo: bimodal or two-speed IT. Rather than solve the problems, bimodal IT solidified the split. Bimodal was often the de facto structure that arose, but it worked best as a transitional strategy.

随着互联网应用变得越来越复杂，它们与遗留系统的集成也变得越来越复杂。这最终导致了痛苦的重组，两个团队重新合并，并且通常使整个组织都标准化敏捷方法。

As Internet applications became more complex, their integration with legacy systems did as well. This eventually led to painful reorganizations, reuniting the two groups, and often standardizing agile methods for the entire organization.

MUSTANG 团队、Alias Systems、Sciex 和 Integrated Financial Software 的故事都涉及技术债务这一主题。随着敏捷专家深入研究企业敏捷实施，了解债务增加的后果以及解决问题的方案变得越来越重要。即使是最敏捷的团队在面对高科技债务时也会进展缓慢。这是一个棘手的问题。

THE MUSTANG TEAM, Alias Systems, Sciex, and the Integrated Financial Software stories touched on the topic of technical debt. As agilists delved into enterprise agile implementations, understanding the consequences of rising debt and options to fix the problem became increasingly important. Even the most agile team advances slowly when faced with high tech debt. It presents a gnarly problem to solve.

IT 和产品经理意识到债务对软件维护能力的破坏性影响，开始了解潜在问题及其解决方法。他们接受了技术债务策略的必要性。Salesforce 的成功经验在本章开头有所描述，该公司在 2000 年代中期发展迅速，但其软件交付能力在这种增长和技术债务的影响下开始衰退。转向敏捷交付模式并提高技术能力推动了该公司的增长。

IT and product managers, who were aware of the devastating effect of debt on their ability to maintain software, were beginning to understand the underlying issues and how to deal with them. They accepted the need for a tech debt strategy. Salesforce, whose successes were described at the beginning of this chapter, was growing rapidly in the mid-2000s, but its software delivery capabilities were faltering in the wake of that growth and tech debt. Switching to an agile delivery model and increasing its technical capabilities fueled this company’s growth.

技术债务问题是软件无形性最严重的后果。金融债务是有形的；它出现在公司的资产负债表上。不断增加的金融债务会限制公司的融资选择，并会影响对创新新产品和服务的投资。软件技术债务更加隐蔽，因为它通常是隐藏的，只有当软件维护成本不断上升，开发人员没有时间开发新产品时才会出现。

Technical debt issues are the most consequential outcome of software’s intangibility. Financial debt is tangible; it shows up on the company’s balance sheet. Increasing financial debt limits a company’s financing options and can impact investments in innovative new products and services. Software technical debt is more insidious because it generally remains hidden, emerging only as software maintenance costs escalate and developers have less time for new products.

技术债务分为两类：质量下降和过时。两者的主要区别在于质量下降是由内部力量还是外部力量造成的。质量下降是由于系统维护不善造成的。过时是由于外部变化（例如从客户端-服务器到互联网架构）迫使人们进行转换。技术债务还会阻碍对新产品的投资。

Two categories of tech debt occur: quality degradation and obsolescence. The primary difference between the two is whether the degradation results from internal or external forces. Quality degradation occurs when systems are poorly maintained. Obsolescence occurs when external change—client-server to Internet architecture, for example—forces a conversion effort. Technical debt can also hamper investment in new products.

敏捷方法为这个问题带来了新的视角——持续交付价值。改变叙述，但不要将质量与有价值的功能对立起来。解释缺乏对管理技术债务的投资如何影响企业的价值交付流。

What the agile methods brought to this issue was a new perspective—one of continuous delivery of value. Change the narrative, but don’t pit quality against valuable features. Explain how a lack of investment in managing tech debt impacts the enterprise’s stream of value delivery.

技术债务的底线是：修复成本高，但忽视成本更高。IT 组织应对互联网时代的能力因技术债务而受损（图 7.3）。

The bottom line for technical debt: It’s expensive to fix, but much more expensive to ignore. IT organizations’ ability to respond to the Internet era was compromised by technical debt (Figure 7.3).

13.该数据最早出现在 Highsmith，2009 年。

13. This figure first appeared in Highsmith, 2009.

迄今为止，影响全球软件和计算机的最大技术债务事件是 1999 年至 2000 年的世纪之交。这次千年虫事件耗尽了 IT 组织的资源，而此时他们正需要集中精力应对互联网的战略影响。

By far, the largest technical debt event that impacted software and computers worldwide was the century transition from 1999 to 2000. This Y2K event drained resources from IT organizations at the very time they needed to focus on responding to the strategic impact of the Internet.

由于过时（还记得 Windows XP 吗？）而造成的技术债务通常需要付出巨大努力，尤其是当转换决策拖延时。通常，这些情况是由于系统软件的进步或重大硬件变化而出现的。这些转换项目很容易被低估，很大程度上是因为 IT 部门不愿意承认它们的实际成本。我曾经与一位面临“必须做”的硬件转换的经理交谈过，估计他的整个部门需要为此工作两年——提供与旧系统完全相同的功能，只是采用了新的技术架构。他担心会失去两年的用户群。他的担心是正确的。

Tech debt caused by obsolescence (remember Windows XP?) typically results in large efforts, particularly when the decision to convert drags out. Often, these situations arise because of advances in systems software or major hardware changes. These conversion projects are prone to underestimation, in large measure, because IT departments are reluctant to admit their real costs. I once talked to a manager facing a “must do” hardware conversion estimated to keep his entire department working on it for two years—to deliver the exact same functionality as the old system, just with a new technology architecture. He was concerned about abandoning his user base for two years. He was right to be concerned.

俗话说“拖延问题”导致了技术债务最恶劣的例子。我遇到的一家休斯顿软件公司向石油行业销售工程应用程序。它的发布周期已激增至两年多，在“代码冻结” 18 个月后还有最后的测试和集成期！公司经理面临着一个艰巨的决定，因为完全替换旧系统的项目估计要花费 1 亿美元以上。他们此时的所有选择都是错误的。此外，我警告说，如果他们不解决他们的技术债务策略，任何全新的系统几年后都会面临同样的退化。

The proverbial “kicking the can down the road” resulted in a most egregious example of tech debt. One Houston-based software company I encountered sold engineering applications to the oil industry. Its release cycle had exploded to more than two years, with a final test and integration period after “code-freeze” of 18 months! Company managers faced a daunting decision since a project to completely replace the old system was estimated to cost upward of $100 million. All of their choices at this point were bad ones. In addition, I cautioned that if they didn’t address their tech debt strategy, any brand-new system would face the same degradation after a few years.

对于大多数企业来说，解决技术债务问题需要采取渐进式改进策略和坚持不懈。鉴于大型企业的软件资产组合多种多样，根据具体应用，需要采取重写、系统重构和放弃这三种债务削减策略。

For most enterprises, fixing tech debt issues requires an incremental improvement strategy and persistence. Given the diverse software asset portfolios of big enterprises, all three of the debt reduction strategies—rewrite, systematic refactoring, and abandoning—will be required depending on specific applications.

扩展敏捷性

Scaling agile

2010 年，我和 Josh Kerievsky 来到中国，为 Cutter Consortium 旗下的中国电信提供咨询服务。我们原本以为这只是一次与几个人讨论问题的正常咨询任务，但没想到，现场竟然有 60 多人，这让我们感到很惊讶，甚至有些害怕。在 10 天的时间里，我们介绍了敏捷概念和实践，回答了问题，并参与了边栏讨论——使用同声传译。对于一条评论（我不记得是谁说的了，因为 Josh 和我有时都很无礼），中文翻译回答道：“我不能这么说！”Josh 和我经常轮流做演讲，这样不做演讲的人就可以快速想出他接下来要说什么。

Josh Kerievsky and I showed up in China in 2010 to consult with Telecom China under the Cutter Consortium banner. Expecting a reasonably normal consulting assignment discussing issues with a few people at a time, we were surprised, and a little daunted, to encounter an audience of more than 60 people. For 10 days, we presented agile concepts and practices, answered questions, and engaged in sidebar discussions—using simultaneous translators. To one comment (I can’t remember who said it since both Josh and I can be irreverent at times), the Chinese translator replied, “I can’t say that!” Josh and I traded off presentations often, so the non-presenter could hurriedly figure out what he was going to say next.

中国电信是一家大型设备制造公司，已实施 IBM 的 Phase-Gate 流程进行产品开发。14软件部门致力于能力成熟度模型 (CMM)。许多敏捷主义者认为，首要任务^是摆脱CMM 和 Phase-Gate 系统。然而，在一家大型制造公司中，消除这种嵌入的流程超出了 Josh 和我的工作范围。因此，我们找到了一种方法，将敏捷软件开发方法嵌入到其整体流程¹⁵中，即使用 Phase-Gate 系统进行治理、使用 CMM 进行定义系统、使用敏捷实践进行运营开发。这是我们对 Sciex 所做工作的延伸。虽然有些笨拙，但确实有效。这足以为软件部门提供引入敏捷的掩护。在大型敏捷转型中，您必须谨慎选择战斗。试图在拥有数千名开发人员的软件部门实施敏捷实践已经足够艰巨，因此坚持在整个组织中改变长期嵌入的管理系统需要在未来阶段进行规划。

Telecom China was a large equipment manufacturing firm that had implemented IBM’s Phase-Gate process for product development.¹⁴ The software division, was committed to the Capability Maturity Model (CMM). Many agilists would argue the first priority would be to get rid of both the CMM and the Phase-Gate system. However, in a large manufacturing company, ousting such embedded processes was beyond the scope of work Josh and I were tasked with. So, we found a way to imbed an agile software development methodology within its overall process¹⁵ by using the Phase-Gate system for governance, CMM for a definitional system, and agile practices for operational development. This was an extension of what we had done with Sciex. Admittedly kludgy, it worked. It was enough to give the software division cover to introduce agile. In large agile transformations, you have to pick your battles carefully. Trying to implement agile practices in a software division of several thousand developers was daunting enough, so insisting on changing long-embedded management systems across the entire organization needed to be planned in a future phase.

14 . 阶段门系统是一种纪念碑式方法论，常见于设计和制造工业产品的公司。它有瀑布式的阶段（规划、设计、工程图等）和作为正式管理控制点的门。门审查通常非常耗时。

14. A Phase-Gate system is a type of Monumental Methodology often found in companies that design and manufacture industrial products. It has waterfall-like phases (plan, design, engineering drawings, etc.) and gates that are formal management control points. Gate reviews are often very time consuming.

15.我写过一篇关于在ASDE中处理 Phase-Gate 和 Agile 的方法(Highsmith, 2002)。

15. I wrote about an approach to handling Phase-Gate and Agile in ASDE (Highsmith, 2002).

我们从这次合作中学到的一件事就是障碍和壁垒之间的区别。当时大多数敏捷主义者将壁垒视为需要克服的挑战，并没有认识到具体类型的障碍。对于大型组织，尤其是其他国家的组织，区分是必要的。我们将障碍定义为可以在敏捷实施中克服的东西。我们认为突破壁垒要困难得多，需要高级管理人员的参与。

One thing we learned from this engagement was the difference between an impediment and a barrier. Most agilists at the time looked at barriers as challenges to overcome and didn’t recognize specific types of barriers. With large organizations, particularly those in other countries, differentiation was necessary. We defined an impediment as something that could be overcome in an agile implementation. We thought breaching a barrier was much, much harder, requiring senior executive involvement.

Josh 和我是否宁愿不绕过阶段门系统？当然。我们是否已经忙于向数千名软件工程师介绍敏捷？当然。当时，试图将敏捷计划融入他们的阶段门系统是唯一可行的方法。多年来，我从与客户的合作中学到的一个教训是，撞墙会让我头疼。我试着不再这样做了。对于大型敏捷转型，了解障碍和壁垒之间的区别对于避免头疼至关重要。

Would Josh and I have preferred not to work around the Phase-Gate system? Certainly. Did we have our hands full introducing agile to the thousands of software engineers already? Absolutely. Trying to fit the agile initiative into their Phase-Gate system was the only feasible way to go, at that time. One lesson I have learned from working with clients over the years is that banging my head against the wall causes headaches. I try not to do that anymore. For large agile transformations, understanding the difference between impediments and barriers is critical to avoiding headaches.

此次旅行的亮点是美食之旅，由时任 Thoughtworks 中国区董事总经理（现为 Thoughtworks 总裁兼首席执行官）的郭晓安排。郭晓点了一桌子我们自己绝对尝不到的中国美食。

A dining adventure highlighting this trip was arranged by Guo Xiao, then managing director of Thoughtworks China (currently president and CEO of Thoughtworks). Xiao ordered a table full of Chinese delicacies that we would never have tasted on our own.

我在中国电信和综合财务软件公司的工作经历进一步证实了敏捷实践可以推广，但仍有批评者将敏捷实践局限于小型项目。我们的工作在 Sciex 和 Integrated Financial Software 的领导下，敏捷已扩展到中型公司和项目。现在，大型组织的挑战来了。在 2011 年的敏捷高管论坛上，我与一位中国软件工程副总裁进行了交谈，他的员工约有 20,000 名工程师。

ENGAGEMENTS LIKE MY work at Telecom China and Integrated Financial Software provided further confirmation that agile practices would scale, but there were still detractors who relegated agile to small projects. Our work at Sciex and Integrated Financial Software saw agile scale to medium-sized companies and projects. Now came the challenge of huge organizations. At the Agile Executive Forum in 2011, I was talking to a Chinese vice president of software engineering whose staff numbered about 20,000 engineers.

“去年你有多少个敏捷项目？”我问道。

“How many agile projects did you have last year?” I asked.

他回答道：“三个。”

“Three,” he replied.

“那么今年你想解决多少个问题呢？”

“And how many do you want to tackle this year?”

“大约200个。”

“Around 200.”

我非常惊讶，以至于很难结束谈话。也许他知道一些我不知道的事情，但根据我的经验，在一年的时间内从 3 个敏捷项目增加到 200 个项目是不可行的。与任何重大变革计划一样，平衡太快和太慢的行动很难，而且正确的方法在不同的组织之间差别很大。说服 IT 高管实施敏捷实践的实际成本和时间是一项挑战，因为他们经常采用另一种形式的基于愿望的规划——基于愿望的敏捷实施。少数人，比如 IFS 和 Sciex 的人，更了解挑战和成本。

I was so surprised I had a hard time finishing the conversation. Maybe he knew something I didn’t, but going from 3 agile projects to 200 in a year’s time wasn’t doable in my experience. As with any major change initiative, balancing moving too fast and moving too slow is hard, and the right approach varies greatly between organizations. Convincing IT executives of the realistic cost and time to implement agile practices was a challenge, because they often employed another form of wish-based planning—wish-based agile implementations. A few, like the ones at IFS and Sciex, better understood both the challenge and the cost.

在数字化转型时期，随着规模化敏捷框架 (SAFe) 和 Disciplined Agile 方法的引入，规模化敏捷开发成为热门话题。SAFe 由 Dean Leffing-well 开发，Disciplined Agile 由 Scott Ambler 开发，他们都是行业先驱。PMI 收购了 Disciplined Agile，私募股权公司 Eurazeo 为 SAFe 注入了巨额资金，这表明人们对规模化方法的兴趣日益浓厚。

In the Digital Transformation period, scaling agile development became a hot topic with the introduction of the Scaled Agile Framework (SAFe) and the Disciplined Agile methodologies. SAFe was developed by Dean Leffing-well and Disciplined Agile by Scott Ambler, both pioneers in the industry. Indicative of the escalating interest in scaling approaches, Disciplined Agile was purchased by PMI, and SAFe received a major capital infusion by private equity firm Eurazeo.

然而，在“勇敢的高管”时期，扩展敏捷开发的具体方法才刚刚出现，公司 CIO 和其他人对此持怀疑态度。第 8 章将再次讨论扩展问题，首先要问我们是否在解决正确的问题。在本章中，我想提出几个论点，即敏捷思维不应局限于小型项目。

However, in the Courageous Executives period, specific methods for scaling agile development were just emerging and company CIOs and others were skeptical. Chapter 8 will address scaling again, first asking if we were even addressing the right questions. In this chapter, I want to offer a couple of arguments that an agile mindset should not be limited to small projects.

我的第一个论点来自 2002 年与麻省理工学院航空航天研究员兼教授 Sheila Widnall 的一次简短交流。她于 1993 年至 1997 年期间担任美国空军部长，是第一位担任该职位的女性，也是第一位领导整个美国军种的女性。Widnall 博士在 2000 年由航空航天公司和空军太空与导弹系统司令部联合主办的风险管理研讨会上发表了主旨演讲。

MY FIRST ARGUMENT comes from a brief interaction in 2002 with Sheila Widnall, an aerospace researcher and professor at MIT. She served as U.S. Secretary of the Air Force between 1993 and 1997, making her the first woman to hold that position and the first woman to lead an entire branch of the U.S. military. Dr. Widnall gave the keynote address at a 2000 Risk Management Symposium jointly sponsored by the Aerospace Corporation and the Air Force Space and Missile Systems Command.

威德纳尔博士在演讲中回顾了去年发射和运载火箭的一系列失败，这些失败促使审查委员会和发射行业重新考虑其任务可靠性方法。她的目标是在系统工程和风险管理方面实现更高水平的效率。

In her talk, Dr. Widnall examined the previous year’s rash of launch and vehicle failures that led to review committees and the launch industry rethinking its approach to mission reliability. Her goal was achieving a higher level of effectiveness in systems engineering and risk management.

然后她提到了我的《自适应软件开发》一书：

She then mentioned my Adaptive Software Development book:

最近，我被 Jim Highsmith 的新书深深吸引，这本书是关于自适应软件开发的。他用登山的比喻，描述了人们在考虑从事一项风险大、复杂的事业时所要考虑的问题，这种事业的结果不可预测，而且一个失误就可能致命：这种事业需要相当的技能、规划和适应能力。他再次将登山的方法与开发一款新的复杂软件的方法进行了比较。

I was quite taken recently with a new book by Jim Highsmith on adaptive software development. Using a mountain climbing metaphor, he traces the considerations one goes through in thinking about undertaking a risky, complex venture, where the outcome is inherently unpredictable and where one misstep can be fatal: a venture that requires considerable skill, planning, and adaptability. And again, the parallels are drawn, and comparisons made between the approach taken to climbing a mountain and that taken in developing a new and complex piece of software.

Widnall 博士想利用ASD中的概念来开发类似的航空航天方法，可能称为自适应系统开发。但她也警告说，虽然对软件的应用很明显，但对系统的应用却不那么明显——她要求听众“思考”这一点。

Dr. Widnall wondered about using the concepts in ASD to develop a similar aerospace approach, possibly called adaptive systems development. But she also cautioned that while the application to software was obvious, the application to systems was less so—something she asked the audience to “think about.”

在得知她的主题演讲后，我又打了一次电话，Widnall 博士说：“也许在航空航天业，新飞机的建造项目需要 10 到 15 年的时间，我们无法使用每周或每月的迭代，但即使是某种两年一次的迭代也会对我们有益。”当然，如果敏捷/自适应概念可以在航空航天项目中发挥作用，那么它们在软件开发中也可能会得到推广。

In a follow-up phone call after I learned about her keynote address, Dr. Widnall offered: “Maybe in the aerospace business, where programs to build new aircraft take 10 to 15 years, we would not be able to use weekly or monthly iterations, but even some type of say two-year iterations would benefit us.” Of course, if agile/adaptive concepts could be helpful in aerospace programs, then they just might scale in software development.

第一台数码相机是由伊士曼柯达公司的工程师史蒂芬·萨森于 1975 年发明的。柯达公司在胶卷相机业务方面获得了巨额利润，销售胶卷和胶卷处理设备。早期的数码相机没有许多相机爱好者想要的分辨率，因此柯达公司的高管继续向胶卷业务投入大量资金。但数码相机也有优势——易于使用、即时查看和低成本。数码相机克服了分辨率不足的问题，一开始进展缓慢，然后进展得越来越快。廉价数码相机市场呈爆炸式增长，然后昂贵的相机也开始转型。胶卷业务一落千丈，柯达公司宣布破产。

THE FIRST DIGITAL camera was developed by Eastman Kodak engineer Steven Sasson in 1975. Kodak made enormous profits on the film side of the camera business, selling both film and film-processing equipment. Early digital cameras didn’t have the resolution many camera buffs desired, so executives at Kodak continued to pour investments into the film business. But digital cameras also had benefits—namely, ease of use, instant viewing, and low cost. First slowly, and then more rapidly, digital cameras overcame their resolution deficiencies. The market for inexpensive digital cameras exploded, and then expensive cameras made the transition. The film business went up in smoke and Kodak declared bankruptcy.

这个故事表明了当今企业面临的持续困境——何时淘汰现有产品，何时推出新产品。时机很棘手。最近，廉价相机市场已被拥有出色相机和许多其他应用程序的智能手机所取代。柯达被克莱顿·克里斯滕森（1997）称为“创新者的困境”所击垮，其中一款具有新吸引力功能的次等产品超越了市场领导者，因为该产品的缺陷在后续版本中得到修复。起初，数码相机成本低，无需胶卷处理，最重要的是即时响应。它们早期的缺点是图像质量较差。但是，对于很大一部分市场而言，即时响应和无需胶卷处理的麻烦比图像质量更重要。然后，随着图像质量的提高，数码相机进一步侵入市场，直到最终胶卷相机成为一种小型专业产品^。16

This story suggests the constant dilemma businesses face today—when to cannibalize their existing products and when to launch new ones. The timing is tricky. Recently, the inexpensive camera market has been overtaken by smartphones that have great cameras and many other applications. Kodak was brought down by what Clayton Christensen (1997) called the “innovator’s dilemma,” in which a lesser product with new desirable features overtakes a market leader as the product’s deficiencies are fixed in subsequent releases. In the beginning, digital cameras had low cost, no film processing, and, best of all, instant response. Their early downside was poorer picture quality. But, for a large segment of the market, instant response and not having the hassle of film processing was more important than picture quality. Then, as their picture quality increased, digital cameras intruded further into the market, until eventually film cameras were a small, specialty item.¹⁶

16.根据系统思维，每个解决方案都会带来新的问题。现在我们的数字设备上有成千上万张大多杂乱无章的图片。以前我们只有一箱又一箱的图片。

16. According to systems thinking, every solution comes with its own new problems. Now we have thousands and thousands of mostly unorganized pictures on our digital devices. Previously we had only boxes and boxes of them.

在敏捷时代的 Rogue Teams 时期，扩展可能是一个问题。17^然而，与数码相机的情况类似，早期的缺陷正在缓慢但稳步地消失。仍然有人反对数码相机，就像有人怀疑敏捷开发的扩展能力一样，但事实证明他们站在了历史的错误一边。

In the Rogue Teams period within the Agile era, scaling may have been an issue.¹⁷ However, similarly to the case for digital cameras, slowly but surely that early deficiency faded. There are still detractors of digital cameras, just as there are skeptics about agile development’s ability to scale, but they are proving to be on the wrong side of history.

17.扩展并不是唯一受到批评的敏捷特性，但是在这里它可以作为一个例子。

17. Scaling isn’t the only agile feature that came under fire, but it will do as an example here.

最后，关于扩展，我问了几个与《敏捷宣言》中表达的价值观相关的问题。在多大规模的项目中，流程和工具比个人及其互动更重要？请记住，《敏捷宣言》使用了特定的词“超过”，意思是流程和工具很重要，但不如个人和协作团队重要。

FINALLY, IN REGARD to scaling, I ask several questions related to the values expressed in the Agile Manifesto. At what size of project do process and tools become more important than individuals and their interactions? Remember, the Agile Manifesto uses the specific word “over,” meaning process and tools are important, just less so than individuals and collaborative teams.

其次，在项目规模达到何种程度时，客户合作的重要性会低于合同？合同当然很重要。但如果没有与客户的合作关系，合同无论多么详细，都无法提供预期的结果——双方都可能受到影响。

Second, at what size of project does customer collaboration become less important than a contract? Contracts are important, certainly. But without a collaborative relationship with the customer, a contract, no matter how detailed, won’t provide the desired outcome—and both parties may suffer.

您可以针对其他敏捷宣言价值观陈述构建类似的问题。虽然大型项目需要以文档、流程和管理评审的形式提供更多方法论护栏，但敏捷思维仍能提供最佳的成功机会。

You can construct similar questions for the other Agile Manifesto value statements. While larger projects require more methodology guardrails in the form of documentation, processes, and management reviews, an agile mindset still offers the best chance of success.

运动员

Athleta

下一个敏捷时代，数字化转型，从关注 IT 敏捷性发展到关注企业敏捷性。Athleta 的故事是业务敏捷性可以实现的早期例子，并为数字化转型时期提供了引导。

The next Agile-era period, Digital Transformation, advanced from a focus on IT agility to enterprise agility. The Athleta story was an early example of what business agility could accomplish and provides a lead-in to the Digital Transformation period.

帕特·里德 (Pat Reed) 给我讲了这个故事，我在会议演讲和研讨会上多次重复讲过这个故事，因为它展示了敏捷思维可以取得的成就。Athleta 成立于 1998 年，旨在满足运动女性的独特需求，2008 年被 GAP 公司收购。高管们面临的一个问题是，是将 Athleta 保留为纯互联网购物体验，还是开设实体店。帕特讲述了这个故事背后的故事。

Pat Reed told me this story, and I’ve retold it many times in conference talks and workshops because it shows what an agile mindset can accomplish. Athleta, founded in 1998 to meet the unique needs of athletic women, was acquired by GAP, Inc., in 2008. A question faced by executives was whether to keep Athleta as an Internet-only shopping experience or to open bricks-and-mortar stores. Pat related the story behind the story.

GAP 高管希望将 Athleta 品牌拓展到实体店，但对此举犹豫不决。为了获得更多可行性信息，他们希望创建一家原型店来测试他们的假设。当他们联系 GAP 设施管理和传统 IT 部门时，预计建设时间是 18 个月。

GAP executives wanted to expand the Athleta brand into brick-and-mortar stores but were hesitant about the move. To gain additional viability information, they wanted to create a prototype store to test their hypothesis. When they approached their GAP facilities management and legacy IT departments, the estimated build-out time frame was 18 months.

Pat Reed 的在线开发部门秉承敏捷思维，意识到这只是一次市场试验，因此协助 GAP 业务负责人在短短三个多月内就在加利福尼亚州米尔谷开设了原型店。在目标市场社区选址时，他们没有建造建筑物，而是租用了建筑物。他们省去了安装企业信息系统通常需要的时间，而是使用了 QuickBooks。他们打破了企业新建建筑的标准，但结果令人鼓舞，因此做出了开设实体店的决定。公平地说，设施部门的任务是建造第 20 或第 50 家商店，而不是原型。在 IT 遗留部门，产品试验不是他们的专业领域——但对于未来十年的变革来说，这必须是他们的专业领域。第一家 GAP Athleta 商店于 2011 年开业，如今全球已有 200 多家商店。Athleta 的故事说明了敏捷性的好处——无论是在管理方面还是在软件开发方面。

Working with an agile mindset and recognizing that this was an experimental probe into the market, Pat Reed’s online development department assisted the GAP business leaders to open the prototype store in Mill Valley, California, in a little more than three months. When siting the store in the target market community, they didn’t construct a building, but rather rented one. They eliminated the time usually taken to install corporate information systems and used QuickBooks instead. They broke corporate new-building standards, but the results were encouraging enough that the brick-and-mortar decision was made. In fairness, the facilities department’s mission was to build the 20th or 50th store, not a prototype. In the IT legacy department, product experimentation was not their area of expertise—but it needed to be for the coming decade of change. The first GAP Athleta store was opened in 2011, and today there are more than 200 stores worldwide. The Athleta story illustrates the benefits of agility—both in management and in software development.

期间观察

Period observations

虽然技术实践得到了磨练，并且出现了 DevOps 和 Kanban 等新实践，但勇敢的高管时代专注于通过改变建立在以下基础上的组织政策，在组织中实施敏捷实践：几十年的瀑布思维、招聘和留任政策、合同条款、领导风格——看似无穷无尽的清单。

While technical practices were honed and new practices like DevOps and Kanban emerged, the Courageous Executives era focused on implementing agile practices in organizations by changing organizational policies built on decades of waterfall thinking, hiring and retention policies, contract terms, leadership style—a seemingly endless list.

组织变革面临诸多障碍，而实施敏捷方法则与其中许多障碍相冲突。值得注意的是，组织障碍遵循了不愿成为敏捷团队一部分的模式。在 Rogue Teams 时期，敏捷团队主要由开发人员组成，因为他们面临着组织变革的障碍，例如审计“职责分离”标准，这使得一些组织无法将测试人员添加到项目团队中。随着自动化测试、持续集成和部署管道的出现，它们为敏捷团队注入了更多变革。

There are many impediments to change in organizations, and implementing agile methodologies ran headlong into many of them. Notably, the organizational impediments followed a pattern of reluctance to become part of agile teams. In the Rogue Teams period, agile teams consisted primarily of developers, as they faced impediments to organizational change such as audit “separation of duties” standards that kept some organizations from adding testers to project teams. As automated testing, continuous integration, and deployment pipelines emerged, they injected additional changes into the mix.

另一个障碍涉及产品管理角色。Scrum 确定了产品负责人，其职责是确定、定义和确定产品功能的优先级。公司没有设计这个新的产品负责人角色，这需要与开发团队面对面交流，而这种遗漏造成了能力差距。内部 IT 部门通常没有产品专家（最接近的角色可能是臭名昭著的主题专家 [SME]），而软件公司通常具有产品管理能力，但还不够。资金和定义产品角色的问题经常发生。

Another impediment involved product management roles. Scrum identified a Product Owner whose job was to identify, define, and prioritize product features. Companies hadn’t designed this new Product Owner role, which required facetime with the development teams, and the omission created a capability gap. Internal IT departments didn’t normally have product specialists (the closest role was probably the infamous subject-matter expert [SME]), while software companies typically had product management capabilities, just not enough. Problems funding and defining product roles happened frequently.

这种对团队角色和职责的重新定义影响了 IT 部门及其他部门的每个职能组——测试、运营、产品管理、数据设计和管理以及用户界面设计。每个领域都不愿意“采用敏捷”，并且可以列举出多种原因来说明为什么敏捷实践不适合他们的职能领域。

This redefinition of roles and responsibilities on teams impacted every functional group in IT and beyond—testing, operations, product management, data design and administration, and user interface design. Each area was reluctant to “go agile” and could cite multiple reasons why agile practices wouldn’t work in their functional area.

敏捷实施中的另一个冲突领域是敏捷团队与项目管理办公室 (PMO) 和项目经理之间的冲突。在 IT 组织中（尽管在软件公司中情况并非如此），PMO 拥有相当大的权力，他们不想放弃。此外，PMO 通常由业务人员而不是 IT 人员组成，并且经常充当 Monumental 方法的“执行者”。项目管理社区在采用敏捷原则方面可能落后了三到五年。（开发团队和 PMO 之间的摩擦由来已久，并不是从敏捷实践的入侵开始的。）

Another area of conflict in agile implementations was between agile teams and project management offices (PMOs) and project managers. In IT organizations (though not as much in software companies), the PMOs wielded considerable power they didn’t want to give up. Furthermore, PMOs were typically staffed by the business personnel rather than IT staff and often served as the “enforcers” of Monumental Methodologies. The project management community was probably three to five years behind in adopting agile principles. (The friction between development groups and PMOs was long-standing and didn’t begin with the incursion of agile practices.)

因此，从流氓团队到敏捷组织的转变是一个坎坷的过程，充满了一个又一个的障碍。一些公司能够突破，而另一些公司则在每个障碍面前受阻。有一句话描述了 Gary Walker 在 Sciex 的经历，值得在此重复：“正如我回想一下，我们在启动敏捷转型大约18个月后才开始看到团队思维方式和行为的变化。”有效的组织变革需要时间和耐心。

So, the transition from rogue teams to agile organizations was a bumpy one, replete with impediment after impediment. Some companies were able to break through, while others were stymied at each roadblock. One sentence describing Gary Walker’s experience at Sciex bears repeating here: “As I recall, we began to see a change in the team mindset and behavior approximately 18 months after we initiated the agile transformation.” Effective organizational change takes time and patience.

我个人的观察是，组织实施敏捷开发的成败取决于那些了解敏捷核心的勇敢高管。Sciex 的 Ken Delcol 不仅鼓励和资助他们的敏捷转型，还提出了一些古怪的做法，比如组建来自多个工程学科的团队并重组工作空间以适应他们。另一个故事中的 Barry 鼓励和资助他的公司实施敏捷，但他从未接受过这些原则。敏捷团队可以在没有勇敢高管参与的情况下取得成功；组织敏捷计划则不能。

My own observation is that success versus failure with organizational implementation of agile development rests with courageous executives who understand agility at their core. Ken Delcol at Sciex not only encouraged and funded their agile transformation, but also proposed such outlandish practices as forming teams from multiple engineering disciplines and restructuring workspaces to accommodate them. Barry, from another story, encouraged and funded his company’s agile implementation, but he never embraced the principles. Agile teams could succeed without courageous executives’ involvement; organizational agile initiatives could not.

另一项观察与实现组织变革的方法有关。敏捷专家在变革模型方面拥有足够的背景知识，能够应付团队级别和小公司的实施。在企业级别，他们经常需要组织变革专家的帮助，但并不总是能得到帮助。当敏捷专家确实得到此类帮助时，情况就不同了。

Another observation relates to the approaches taken to effect organizational change. Agilists had enough background in change models to muddle through team-level and small-company implementations. At an enterprise level, they often needed help from organizational change experts, but didn’t always get it. It made a difference when agilists did receive such assistance.

总体而言，我经历了两个时代（结构化和敏捷），结果表明敏捷转型的成功率高于早期的纪念碑式方法论计划，尽管敏捷社区对成功的定义存在广泛争议。成功的原因在于：（1）业务收益显而易见；（2）敏捷实践对开发人员很有吸引力（而之前的方法论对这一群体的吸引力不大）；（3）《敏捷宣言》明确阐述了这项运动的目的和原则。20 世纪 80 年代和 90 年代重量级的瀑布方法论是文档驱动和官僚主义的，其实施由上层（管理层）向下层（工程师）推动。敏捷实施大部分由开发人员推动或支持。

Overall, my experiences in two eras (Structured and Agile) showed the success rate for agile transformations was higher than that for earlier Monumental Methodology initiatives, although what constituted success was widely debated in the agile community. The reasons for this success were: (1) The business benefits were demonstrable; (2) agile practices appealed to developers (whereas previous methodologies had little appeal to this group); and (3) the Agile Manifesto stated a clear purpose and principles for the movement. The heavy-weight waterfall methodologies of the 1980s and 1990s were document driven and bureaucratic, and their implementation was driven from the top (management) to the bottom (engineers). Agile implementations have, for the most part, been either driven by or supported by developers.

Thoughtworks

Thoughtworks

在敏捷时代的头十年，我与 Cutter Consortium 合作。在第二个十年，我去了 Thoughtworks (TW) 工作。1997 年，我遇到了 Martin Fowler，他当时在 TW 工作（现在还在工作）；在悉尼、伦敦和美国各地遇到了其他 TW 员工并与他们共事；还认识了当时的首席执行官 Roy Singham。2010 年，在佛罗里达州奥兰多与 Roy 共进早餐后，我加入了 TW，担任执行顾问。不久之后，我在澳大利亚悉尼的一次敏捷会议上宣布了这一消息，当时我正在发言。

Throughout the first decade of the Agile era, I worked with the Cutter Consortium. During the second decade, I went to work for Thoughtworks (TW). In 1997, I met Martin Fowler, who worked for TW (and still does); bumped into and worked with other TWers in Sydney, London, and various places in the United States; and got to know Roy Singham, then CEO. After a 2010 breakfast with Roy in Orlando, Florida, I joined TW as an executive consultant. The announcement was made shortly thereafter at an agile conference in Sydney, Australia, where I was speaking.

再次成为一名员工绝对是一种改变。但我肯定会为一家敢于冒险的公司工作。对我来说，这段时间标志着节奏的改变。我与客户高管和经理进行短期合作，而不是长期的咨询工作。我的 TW 工作包括敏捷实施咨询、写作、加强高管沟通以及从事数字化转型工作。

Becoming an employee again was definitely a change. But I was certainly going to work for an adventurous company. For me, this period was marked by a change of pace. I worked on short-term engagements with customer executives and managers rather than lengthy consulting gigs. My TW portfolio included consulting on agile implementations, writing, enhancing executive communications, and working on digital transformations.

自 20 世纪 90 年代末，著名书籍作者和《敏捷宣言》合著者 Martin 加入公司以来，TW 员工一直是敏捷方法的主要倡导者。TW 文化是我决定在那里工作的关键因素，因为它涵盖了软件卓越性、IT 转型、社会行动和多样性。它对这些领域的支持远不止口头支持。TW 是一个富有冒险精神的组织，敏捷开发是其核心竞争力。例如，XP 实践包括结对编程（两个开发人员共同编写代码）。如果这对程序员有好处，那么对经理来说可能也很好，所以 TW 尝试了结对编程。与所有实验一样，有些方面比其他方面效果更好。我预计我的任期只有几年；结果持续了 10 年。我与一群极具天赋的人一起工作——技术、管理和高管。

TW staff have been leading proponents of agile approaches since the late 1990s, when Martin, author of well-known books and co-author of the Agile Manifesto, joined the company. TW culture was a key factor in my decision to work there because it included software excellence, transforming IT, social action, and diversity. It gave much more than lip service to all of these areas. TW was an adventurous organization in which agile development was a core competency. For example, XP practices included pair programming (two developers co-writing code). If it was good for programmers, maybe it was good for managers, so TW experimented with pairing them. As with all experiments, some aspects worked better than others. I expected my tenure to be a few years; it lasted 10. I worked with a group of extremely gifted people—in technology, in management, and in the executive suite.

在本世纪初，我经常出差，与《纽约时报》的客户合作，并在会议上发言。我参与了《纽约时报》的内部项目，其中包括两个专注于沟通的项目。我们制定了一份指南，其中包含一些技巧如何提高写作技巧并让想法坚持下去。我们试图让指南保持简单，并包含以下内容：

In the early years of the decade, I traveled widely to work with TW clients and speak at conferences. I worked on internal TW projects, including two that focused on communications. We developed a guideline with tips on how to improve writing skills and get ideas to stick. We tried to keep the guide simple, and light with items like these:

• 不要在不需要帮助的动词上添加介词。不要说“私人朋友”，而要说“朋友”。

• Don’t drape prepositions onto verbs that don’t need help. Don’t say “personal friend,” say “friend.”

• 使用简短的单词，不要使用长的单词。协助（帮助）。众多（许多）。

• Use short words, not long ones. Assistance (help). Numerous (many).

• 大多数副词都是不必要的，而且会使内容更加混乱。

• Most adverbs are unnecessary and add to the clutter.

• 大多数形容词也是不必要的。

• Most adjectives are unnecessary, too.

我还创建了一个讲故事研讨会，其理念是：“光有好的想法是不够的；你必须让这些想法有趣且可信，以便付诸行动。” 2014 年年中，Fiona Lee、Tony Maitz、Dutch Steutel 和我于旧金山举办了第一届讲故事研讨会。研讨会的目标是“提高你影响、吸引和激励他人的能力”。团队开发并展示自己的故事，然后对其进行改进。Tony 原来是帮助团队克服困难的专家。我们用自己的故事来说明讲故事的各个方面，Chip 和 Dan Heath 的 SUCCESs 框架指出，要想让想法具有粘性，就需要简单、出乎意料、具体、可信、感性，并与故事相关。

I also created a storytelling workshop with the thought, “It’s not enough to have good ideas; you must make those ideas interesting and credible enough to be acted upon.” Fiona Lee, Tony Maitz, Dutch Steutel, and I presented the first Storytelling workshop in San Francisco in mid-2014. The workshop’s objective was “To improve your ability to influence, engage, and inspire others.” Teams developed and presented their own stories and then refined them. Tony turned out to be an expert at assisting teams through their struggles. We used our own stories to illustrate various aspects of storytelling, and Chip and Dan Heath’s SUCCESs framework, which says to be sticky, ideas need to be Simple, Unexpected, Concrete, Credible, Emotional, and tied to Stories.

2013 年，我收集了过去五年的博客文章，并发表了《适应性领导力》（Highsmith，2013 年）。它融合了我过去十年与勇敢的高管合作实施大规模敏捷项目时学到的关于领导力的知识，并涵盖了以下主题：

In 2013, I gathered blog posts from the previous five years and published Adaptive Leadership (Highsmith, 2013). It incorporated what I had learned about leadership from the previous decade of collaborating with courageous executives on large agile implementations, and included the following topics:

• 研究高变化环境中的机会流

• Examining the flow of opportunities in high-change environments

• 定义战略、投资组合和运营敏捷性

• Defining strategic, portfolio, and operational agility

• 详细研究价值持续流动的原因和方式

• Examining in detail both the why and how of continuous flow of value

• 建立适应性创新文化

• Building an adaptive, innovative culture

• 在混乱、矛盾的情况下做出决定

• Making decisions in chaotic, paradoxical situations

我在适应性领导力方面的工作促成了我的第一次环球旅行——尽管它只持续了 2 周，而不是 80 天。3^当我计划去澳大利亚参加一个敏捷会议并拜访悉尼的几位 TW 客户时，Roy Singham 打电话问我是否可以在即将于德国慕尼黑举行的 TW 领导力会议上主持一个精简版的适应性领导力研讨会。我发现，除非会议恰逢你的婚礼日期，否则你不会拒绝公司 CEO 的邀请。另外，我很高兴能与高层管理人员分享我的想法。我的旅行路线是从佛罗里达州的威尼斯到伦敦，再到慕尼黑，再回到伦敦，再到悉尼，然后从悉尼直飞德克萨斯州的达拉斯，最后回家。回想这种旅行比实际经历它更有趣。

My work on adaptive leadership generated my first around-the-world trip—though it lasted 2 weeks, not 80 days.³ As I was planning a trip to Australia to speak at an agile conference and visit with several TW clients in Sydney, Roy Singham called and asked if I could present a condensed Adaptive Leadership workshop at an upcoming TW leadership meeting in Munich, Germany. I’ve found that you don’t say no to the company CEO unless the meeting falls on your wedding date. Plus, I was excited to share my ideas with senior management. My route of travel took me from Venice, Florida, to London, to Munich, back to London, on to Sydney, a long direct flight from Sydney to Dallas, Texas, and finally home. It’s more fun to look back on this type of trip than to actually experience it.

3. “80 天”出自儒勒·凡尔纳 1872 年出版的著作《八十天环游地球》。

3. The “80 days” reference is from Jules Verne’s 1872 book, Around the World in Eighty Days.

然后参加了一次会议，集中讨论了我在 Thoughtworks 的剩余时间。

Then came a meeting that focused my remaining time at Thoughtworks.

“当客户询问我们扩展敏捷的方法时，我们应该如何回应？”这个问题促成了 2015 年的 TW 会议。扩展方法越来越受到关注，各公司也纷纷响应这一趋势。时任 TW 亚太区集团董事总经理的 Angie Ferguson 在旧金山发起了这次会议。时任首席能力官的 Chad Wathington、数字转型负责人 David Robinson、产品负责人 Linda Luu 和我一起讨论了 TW 的扩展方法。

“HOW SHOULD WE respond to customers who ask about our approach to scaling agile?” was the question that precipitated a TW meeting in 2015. Scaling approaches were gaining attention and companies were responding to this trend. Angie Ferguson, then TW’s group managing director for the Asia Pacific region, initiated the meeting in San Francisco. Chad Wathington, then chief capabilities officer; David Robinson, digital transformation principal; Linda Luu, product principal; and I met to discuss TW approach to scaling.

当旧金山团队苦苦思索如何在 IT 组织内推广敏捷实践时，我们意识到这并不是一个正确的问题。正确的问题是“我们如何推广整个企业的敏捷性和创新？”第一个是 CIO 的问题。第二个是 CEO 的问题。

As the San Francisco group wrestled with the question of scaling agile practices within an IT organization, we realized it wasn’t really the right question. The right question was “How do we scale enterprise-wide agility and innovation?” The first was a CIO question. The second was a CEO question.

到那时，扩展敏捷软件方法又回到了传统做法，而这些做法很快就升级为官僚主义，进而扼杀了创新。要在数字企业时代取得成功，每个个人、团队、部门、分部和高管团队都需要创新。关键的战略优势不在于规模扩大，而在于大规模创新——不仅在 IT 领域，而且在整个企业中都保留学习和适应的能力。

To that point, scaling agile software methods fell back on traditional practices that quickly escalated into bureaucracy, which then stifled innovation. To succeed in the era of digital enterprises, every individual, team, department, division, and executive suite needed to innovate. The key strategic advantage lies not in size scaling, but rather in innovating at scale—retaining the ability to learn and adapt not just in IT, but across the entire enterprise.

TW 团队有几个担忧，主要集中在对适应性的需求日益增长，以及在不失去适应性的情况下可以扩展的运营模式和投资组合管理方法。我们认为解决方案需要像早期的敏捷方法一样前卫，而不是像几种流行的方法那样安全扩展方法。EDGE 应运而生，它成为了 TW 数字战略的关键部分，也是David、Linda 和我合著的《EDGE：价值驱动的数字化转型》一书的开端（Highsmith、Luu 和 Robinson，2020 年）。

The TW group had several concerns that centered on the growing need for adaptability and an operating model and portfolio management approach that would scale without losing that adaptability. We thought the solution needed to be edgy like early agile methods, not safe like several prevailing scaling approaches. What emerged was EDGE, which became a key part of TW’s digital strategy and the beginnings of a book, EDGE: Value-Driven Digital Transformation, authored by David, Linda, and me (Highsmith, Luu, and Robinson, 2020).

世界正在加速

A world accelerating

数字化企业、第四次工业革命、精益企业——文献中充斥着从旧事物向新事物转变的劝告。企业如何应对？他们是否制定了数字化战略？他们将如何实现这一战略？在充满指数级机遇的世界中，企业是否获得了增量成果？无论目标是成为数字化企业、促进广泛创新还是实施数字化战略，战略是否因执行不力而受阻？

Digital enterprise, the Fourth Industrial Revolution, Lean enterprise—the literature teemed with exhortations to transform from the old to something new. How were enterprises responding? Did they have a digital strategy in place? How were they going to realize that strategy? Were enterprises getting incremental outcomes in a world of exponential opportunities? Whether the goal was to become a digital enterprise, foster widespread innovation, or implement a digital strategy, was strategy being thwarted by poor execution?

这十年见证了南非前总统纳尔逊·曼德拉的逝世、为医学研究筹集 1 亿美元的“冰桶挑战”、巴基斯坦活动家马拉拉·优素福扎伊获得诺贝尔奖以及巴黎气候协定。在技术领域，苹果推出了 iPad，成为首家市值超过 10 亿美元的上市公司。

This decade saw the death of the former president of South Africa, Nelson Mandela; the Ice Bucket Challenge, which raised $100 million for medical research; Malala Yousafzai, Pakistani activist, winning the Nobel Prize; and the Paris Climate Accord. In the technology realm, Apple introduced the iPad and became the first public company to surpass the $1 billion valuation mark.

在 Cynefin 框架中，这一时期的前半段将被视为混乱时期，需要采用新的战略方法。但从 2020 年开始，世界进入了一个混乱时期——这是一个巨大的未知数，即使是新方法也可能不够好。

In the Cynefin framework, the early half of this period would be considered chaotic, a time when novel approaches to strategy were needed. But from 2020, the world entered a time of disorder—a vast unknown, when even novel approaches may not be good enough.

麻省理工学院信息系统研究中心 (CISR) 于 2017 年对全球高层领导进行了一项调查，其中 413 名高管表示，未来五年内，他们的公司可能会数字化颠覆将导致平均收入损失 28%。（Weill 和 Stephanie Woerner，2018 年）

In a 2017 survey conducted by the MIT Center for Information Systems Research (CISR) of senior leadership from across the globe, 413 senior executives reported that over the next five years their companies may be at risk of losing an average of 28 percent of their revenues because of digital disruption. (Weill and Stephanie Woerner, 2018)

我们社会正在经历一场势不可挡的革命，几乎影响到每个人。这场革命由我们一些最大、最受尊敬的公司在众目睽睽之下进行。任何有眼睛的人都能看到。这是一场组织运作方式的革命。（Denning，2018 年）

An unstoppable revolution is now under way in our society, affecting almost everyone. The revolution is being conducted in plain sight by some of our largest and most respected corporations. It’s visible to anyone with eyes to see. It’s a revolution in how organizations are being run. (Denning, 2018)

我们正在经历一个类似于生物学家所说的间断平衡（PE）的商业事件。生物学家在过去的 5 亿年中发现了五个间断平衡，导致恐龙灭绝的事件就是其中之一。在间断平衡事件期间，达尔文的适者生存概念并不重要。陨石撞击前生态系统中适应能力最强的恐龙（霸王龙）在生态系统天气急剧变化时死亡。有少数冷血爬行动物幸存下来（鳄鱼），但新的生态系统青睐那些能够适应恶劣天气变化的动物—​​—温血哺乳动物^。5

We are experiencing a business event analogous to what biologists call a punctuated equilibrium (PE). Biologists have identified five PEs in the last 500 million years—the event that caused the demise of the dinosaurs was one. During PE events, Darwin’s concept of the survival of the fittest did not matter. The fittest dinosaurs in the pre–meteor strike ecosystem (Tyrannosaurus rex) died when the ecosystem weather changed drastically. There were a few cold-blooded reptile survivors (crocodiles), but the new ecosystem favored those that could adapt to severe weather changes—the warm-blooded mammals.⁵

5.本章使用并编辑了《EDGE》 （Highsmith、Luu 和 Robinson，2020 年）一书中的几段文字。

5. In this chapter, several passages from the book EDGE (Highsmith, Luu, and Robinson, 2020) have been used and edited.

比恐龙灭绝事件更鲜为人知的是 2.25 亿年前的灾难性二叠纪晚期事件，当时地球上 96% 的生物物种都消失了（Gould，2002 年）。数百种物种在二叠纪灭绝事件中灭绝，其中许多物种在环境中适应能力极强。有些物种在狭小的生态位中勉强生存下来，却碰巧具备了在随后的三叠纪时期蓬勃发展的特征。

Less known than the dinosaur extinction event was the catastrophic late Permian event, 225 million years ago, when 96% of all living species vanished from earth (Gould, 2002). Hundreds of species, many superbly honed as the fittest in their environment, died in the Permian extinction. Some, barely surviving in small ecological niches, accidentally happened to have characteristics allowing them to flourish in the subsequent Triassic period.

如果达尔文是正确的，他的适者生存理论解释了我们如何适应生物或经济主体的正常变化。如果霍兰德（1995）是正确的，他的适者生存概念（本书第 4 章介绍）解释了我们如何适应变化的速度加快，我们需要转向。如果我们真的处于 PE 的阵痛之中（斯诺登⁶可能会称之为无序领域，而且可能还没有找到有效的方法），那么我们可能正处于一个幸运者生存的时代。

If Darwin was correct, his survival of the fittest explains how we adapt to normal changes in biological or economic agents. If Holland (1995) was correct, his arrival of the fittest concept (introduced in Chapter 4 of this book) explains how we adapt when the pace of change accelerates, and we need to pivot. If we are truly in the throes of a PE, which Snowden⁶ might call the area of disorder and for which effective methods are probably unknown, then we are probably in an era of survival of the luckiest.

6 . https://thecynefin.co/about-us/about-cynefin-framework

6. https://thecynefin.co/about-us/about-cynefin-framework

在强者生存的时代，您应该如何应对？您的组织类似于恐龙还是哺乳动物？二叠纪会有类似物种吗？除了运气之外，哺乳动物繁荣的关键是什么？适应性、适应性、还是适应性。贵组织蓬勃发展的关键是什么？适应性、适应性、还是更多的适应性。这应该是贵组织数字化转型的重点。想一想在 COVID-19 大流行期间拉美航空等航空公司发生了什么。空中交通量瞬间跌至历史最低水平。航空公司大幅削减了变动成本，但航空公司是固定成本很高的业务，因此削减成本的机会有限。净收入急剧下降，在最坏的情况下导致破产。然后，随着疫苗变得可行并可用，航空旅行又飙升回升。航空公司从努力削减运力开始努力增加运力。

In an era of survival of the luckiest, what should be your response? Is your organization analogous to a dinosaur, or a mammal? Will there be a Permian equivalent? What was the key to mammalian thriving, besides luck? Adaptability, adaptability, and adaptability. What is the key to your organization’s thriving? Adaptability, adaptability, and more adaptability. That should be your focus for your organization’s digital transformation. Think about what happened to airlines like Latam during the COVID-19 pandemic. Instantly air traffic plummeted to record lows. Airline companies slashed variable costs, but airlines are a business with high fixed costs, so their cost-cutting opportunities are limited. Net incomes dove precipitously downward, causing bankruptcies in the worst cases. Then, as vaccines became viable and available, air travel rocketed back upward. From struggling to cut capacity, airlines began struggling to increase capacity.

在这个动荡和不确定的时期，一个组织（从首席执行官办公室到前线员工）的适应能力将决定未来的成败。

In this volatile and uncertain time, an organization’s ability to adapt, from the CEO’s office to front-line workers, will determine success, or failure, in the future.

数字化转型

Digital transformation

我在 TW 的最后五六年大部分时间都在致力于数字化转型和 EDGE。在最初的 EDGE 会议之后，David、Linda 和我为 TW 顾问开发了一本内部 EDGE 工作手册，然后收集了客户参与观察，了解该流程的运作情况。《EDGE：价值驱动的数字化转型》于 2020 年出版。EDGE 成为 TW 数字化转型和运营服务产品的一部分。以下是我们在开发 EDGE 过程中学到的知识以及自本书出版以来出现的新材料的概述。

The bulk of my last five to six years at TW was spent working on digital transformation and EDGE. After the original EDGE meeting, David, Linda, and I developed an internal EDGE workbook for TW consultants and then gathered client engagement observations on how the process was working. EDGE: Value-Driven Digital Transformation was published in 2020. EDGE became a component of TW’s digital transformation and operations service offering. What follows is an overview of what we learned while developing EDGE and new material that has emerged since our book’s publication.

我们发现，CEO 们在问：“我们如何才能创建响应式组织？”而 CIO 们则在问：“我们的组织如何才能利用我们的 IT 能力？”在 2022 年 7 月的麦肯锡季度报告中，技术专家 Marc Andreessen 回答了一个关于如何以这样的方式对大公司进行数字化转型的采访问题：“找到公司中最聪明的技术专家，并让他们担任 CEO。” ⁷

We found CEOs were asking, “How can we create responsive organizations?” while CIOs were asking, “How can our organizations take advantage of our IT capability?” In the July 2022 McKinsey Quarterly Report, technologist Marc Andreessen answered an interview question about how to digitally transform big companies this way: “Find the smartest technologist in the company and make them CEO.”⁷

7 . www.mckinsey.com/industries/technology-media-and-te communications/our-insights/find-the-smartest-technologies-in-the-company-and-make-them-ceo

7. www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/find-the-smartest-technologist-in-the-company-and-make-them-ceo

技术进步加剧了机会增长率与利用这些机会的能力发展速度之间的差距（图 8.1）。许多企业面临着机遇和威胁，但缺乏利用它们的能力。这种不断扩大的机会与能力差距成为高管们面临的关键问题。

Technological advances intensify the difference between the rate of opportunity growth and the rate at which the capabilities to take advantage of those opportunities are developed (Figure 8.1). Many enterprises faced opportunities and threats but lacked capabilities to take advantage of them. This growing opportunity–capability gap became a critical issue for executives.

CIO 和 CEO 需要重新思考组织的 IT 战略，将其从功能级战略（与业务战略保持一致但始终从属于业务战略）升级为总体数字业务战略。后者被定义为“通过利用数字资源创造差异化价值而制定和执行的组织战略”（Bharadwaj，2013 年）。

CIOs and CEOs needed to rethink their organizations’ IT strategy, escalating it from a function-level strategy—aligned but always subordinate to business strategy—to an overarching digital business strategy. The latter is defined as “organizational strategy formulated and executed by leveraging digital resources to create differential value” (Bharadwaj, 2013).

制定数字业务战略比弄清楚如何实施它更容易。我们发现，培养从战略到行动的能力涉及五个方面：

Defining a digital business strategy was easier than figuring out how to implement it. As we discovered, developing the capability of moving from strategy to action involves five areas:

• 成功的衡量标准：数字化业务转型需要现代的绩效衡量标准。

• Measures of success: Digital business transformation needs modern performance measures.

• Tech@Core：技术必须融入所有领导者的核心能力中。

• Tech@Core: Technology must be woven into the core capabilities of all leaders.

• 运营模式：转型需要一个快速、有效的过程来确定如何通过价值驱动的投资组合将战略与行动联系起来实施战略。

• Operating model: Transformations require a fast, effective process for determining how to implement strategy by linking it to action through a value-driven portfolio.

• 组织模型：组织结构必须强调价值流而不是功能，并使这些结构具有高度的可塑性。

• Organizational model: Organizational structures must emphasize value streams rather than functions and make those structures highly malleable.

• 共情管理：⁸无论你喜欢什么名字，数字时代的“现代”管理都必须适应。

  8.我一直将共情管理作为一个概括性术语使用。适应性领导将是共情管理的一个例子。

• Empathetic management:⁸ Whatever name you prefer, “modern” management in the digital era must adapt.

  8. I’ve been using empathetic management as an encompassing term. Adaptive leadership would then be an instance of empathetic management.

这里显示的前三个和最后一个区域在 EDGE 中有所涵盖：组织模型来自不同的来源。

The first three and the last area shown here were covered in EDGE: the organizational model comes from a different source.

记住敏捷项目的教训：要改变行为和文化，你必须改变成功的衡量标准。战略层面也必须如此。就像项目层面的敏捷转型一样，说服高管和经理改变他们的成功衡量标准被证明是件很难的事^。9

Remember the lesson from agile projects: To change behavior and culture, you must change measures of success. The same must happen at the strategic level. Just as in project-level agile transformations, convincing executives and managers to change their measures of success proved to be sticky.⁹

9.有关数字化转型的另一种全面观点（其名称有些前卫），请参阅 Sanjiv Augustine 的（nd）“Business Agility SPARKS”。

9. For another comprehensive view of digital transformation with an edgy name, see Sanjiv Augustine’s (n.d.) “Business Agility SPARKS.”

有一天，我和一家知名敏捷软件工具供应商的员工共进午餐，其中一位员工在吹嘘他们的工具能够将速度从团队提升到组织层面。我对这种速度的使用感到震惊，于是我写了一篇博客文章，题为“速度正在扼杀敏捷性”（网上不再提供）。我没有预料到会有这样的反应——流量大到让我的网站崩溃。

AT LUNCH ONE DAY WITH staff from a prominent agile software tool vendor, one was touting their tool’s ability to roll up velocity from teams to the organizational level. I was so aghast at this use of velocity I wrote a blog post titled “Velocity Is Killing Agility” (no longer available online). I wasn’t prepared for the reaction—the traffic volume crashed my website.

詹姆斯·米切纳比欧内斯特·海明威写得好，是因为他的书更长吗？还是因为他每分钟能更快地打出 20 个字？有道理——对吧？根据单位生产力（活动）指标来评估作家的效率毫无意义。如果你的工作是写 Java 代码“字”，而不是写英文（或法文或波兰文）字，类似的生产力指标也没有意义。

Was James Michener a better writer than Ernest Hemingway because his books are longer? Or because he could type 20 words per minute faster? Makes sense—right? Assessing the effectiveness of writers based on per-unit productivity (activity) measures makes no sense. If your job is to write Java code “words” rather than English (or French or Polish) words, similar productivity measures make no sense, either.

生产力指标是针对有形事物的，例如一台机器一小时内可以生产多少个小部件。生产力指标从来就不是用来评估创意和创新等无形事物的。但衡量无形事物很难，衡量有形事物很容易，所以人们自然会倾向于最简单的事物，即使它是错误的。有指标总比没有指标好——对吧？不！给我一个模糊的（或相对的）任何时候，我们都会使用对有价值事物（结果）进行衡量的标准，而不是对不重要事物（输出）进行精确衡量的标准。

Productivity measures are meant for tangible things, such as how many widgets a machine can manufacture in an hour. Productivity measures were never designed to assess intangibles such as ideas and innovations. But measuring intangibles is hard and measuring tangibles is easy, so naturally people gravitate toward what is easiest, even when it’s wrong. Better to have some measure rather than nothing—right? No! Give me a fuzzy (or relative) metric of something valuable (an outcome) rather than a precise metric for something unimportant (an output) any time.

不幸的是，生产力狂热跟随我们进入了敏捷时代。太多组织仍然痴迷于限制其敏捷性的生产力指标。速度是披上新外衣的代码行。10敏捷主义者^多次表示，“使用速度作为能力指标，而不是生产力指标”，速度不可避免地使团队对立，并破坏价值和质量。速度是一种数量指标（输出），每次都会给我们带来麻烦。

Unfortunately, productivity mania has followed us into the Agile era. Too many organizations are still obsessed with productivity measures that limit their agility. Velocity is lines of code dressed up in new clothing.¹⁰ As many times as agilists say, “Use velocity as a capacity indicator, not a productivity measure,” velocity inevitably sets teams against teams and undermines both value and quality. Velocity is a quantity measure (output), and it gets us in trouble every time.

10.速度是一个更好的测量方法，因为它是相对的而不是绝对的，这使得它更容易确定。

10. Velocity is a better measure because it is relative rather than absolute, which makes it easier to determine.

在杰里·温伯格的质量研讨会上，他会问：“我保证一个应用程序没有缺陷，这个应用程序可以计算斯坦利·琼斯（1945 年至 1964 年在俄亥俄州机动车辆部工作）的生物节律，你会付给我多少钱？”对于 99.99% 的人来说，这个应用程序的价值为零，所以谁在乎开发团队每次迭代交付 50 个故事还是 3 个故事呢？

In Jerry Weinberg’s quality workshop, he would ask, “What would you pay me for an application that I guarantee has no defects that calculates the biorhythms of Stanley Jones, who worked in the Ohio Department of Motor Vehicles from 1945 to 1964?” The value of that app, for 99.99% of people, would be zero, so who cares if the development team delivered 50 stories per iteration or 3?

当我们探索新产品、新服务、新营销计划或新商业模式时，生产力指标甚至毫无意义。创新的想法、有价值的故事、高质量的代码、缩短的周期时间——这些都是当今环境下衡量成功的更好指标。根据故事速度比较两个开发两种不同新产品、从事两种不同业务职能、使用两种不同技术堆栈的团队，就像使用打字速度作为标准来判断米切纳比海明威更优秀一样有意义。一定有更好的方法。

When we are exploring new products, services, marketing programs, or business models, productivity measures make even less than no sense. Innovative ideas, valuable stories, high-quality code, reduced cycle times—these are better measures of success in today’s environment. Comparing two teams who are working on two different new products, in two different business functions, using two different technology stacks, based on their story velocities makes as much sense as using typing speed as the criterion to decide Michener is a better writer than Hemingway. There has to be a better way.

更好的做法需要清晰地了解从给定投资组合中获得的价值。例如，根据客户满意度衡量客户价值目标的进展情况与关注投资回报率 (ROI) 会推动不同的行为。

Better requires a clear understanding of the value to be derived from a given portfolio. For example, measuring progress toward a customer value goal based on customer satisfaction will drive a different behavior than focusing on return on investment (ROI).

企业确实需要一套内部成功衡量标准。收入、利润、市场份额和上市时间是企业所期望的“商业利益”衡量标准，但客户并不认为这些是有价值的东西（除非他们想知道他们的供应商是否有经济能力）。商业利益可以作为“护栏”或约束。你不希望客户满意而没有利润，但如果做得正确，提高客户价值也会带来商业利益。

Enterprises do need a set of internal measures of success. Revenue, profit, market share, and time to market are measures of “business benefits” desirable to an enterprise, but not something a customer sees as valuable (except they want to know their suppliers are financially viable). Business benefits are useful as “guardrails” or constraints. You don’t want delighted customers and no profit, but if done correctly, improving customer value accrues business benefits as well.

还有第三种企业成功衡量标准——可持续性。过去，企业优化供应链以降低成本。

And there is a third kind of enterprise measure of success—sustainability. In the past, companies have optimized supply chains to reduce costs.

鉴于当今的地缘政治形势，本地可用性可能比成本更重要。您是否会花费大量成本建立多个供应链，以提高可持续性？您的环境可持续性目标是什么？等待某事发生并依靠您的适应能力是一回事；建立一个具有更强适应能力的可持续企业则更好。如果您将技术债务视为可持续性问题而不是质量问题，结果会怎样？

Given the geopolitical situation today, local availability may be more important than cost. Do you build multiple supply chains, at significant cost, in an effort to increase sustainability? What are your environmental sustainability goals? Waiting for something to happen and relying on your ability to adapt is one thing; building a sustainable enterprise having a greater capability to adapt is even better. What if you approach technical debt as a sustainability issue, rather than a quality issue?

如今，为了生存和发展，企业必须解决三个高水平的敏捷性成功衡量标准，如图 8.2所示：始终如一地提供客户价值（满意度）、促进业务利益（投资回报率、销售增长）以及建立可持续（适应性）企业。请注意上一句中使用的是敏捷性而不是敏捷。敏捷方法可能会来来去去；企业敏捷性的需求不会。

To survive and thrive today, enterprises have to address three high-level agility measures of success, shown in Figure 8.2: consistently deliver customer value (satisfaction), foster business benefits (ROI, sales growth), and build a sustainable (adaptive) enterprise. Note the use of agility rather than agile in the preceding sentence. Agile methodologies may come and go; the need for enterprise agility will not.

在执行力时代，生产力和财务指标占据主导地位。在专业知识时代，生产力指标向效率指标转变。11^当我们回顾稳步增长的标准普尔 500 指数中的公司被收购、宣布破产或大幅下滑，我们必须怀疑在高度变化时期是否应依赖传统的财务指标。

In the execution age, productivity and financial measures reigned. During the expertise era, there was a transition from productivity to effectiveness measures.¹¹ When we look back at the steadily increasing number of S&P 500 companies that have been bought out, declared bankruptcy, or drastically declined, we must wonder about relying on traditional financial measures during periods of high change.

11.在讨论成功的衡量标准时，我假设财务指标很重要，因此不会深入探讨它们。

11. In this discussion of measures of success, I assume that financial measures are important and therefore don’t delve into them.

构建数字化转型框架的下一个组成部分是 Tech@Core。

The next component in building a framework for digital transformation is Tech@Core.

科技@核心

Tech@Core

Tech@Core 是 Thoughtworks 创造的一个短语，强调了技术作为业务核心的重要性。

Tech@Core, a phrase coined at Thoughtworks, identifies the importance of technology being at the core of business.

包括首席执行官在内的各级企业领导者都必须精通技术。在 2017 年的一项研究 (Guo, 2017) 中，TW 发现“勇敢的高管知道掌握技术的来龙去脉：54% 的高管对技术有着深刻的理解，57% 的高管编写过代码。”

Enterprise leaders, at all levels including CEOs, must be tech-savvy. In a 2017 study (Guo, 2017), TW found that “Courageous executives know grasping the ins and outs of technology matters: 54% have developed a deep understanding of technology and a remarkable 57% have written code.”

技术成本和效率重要吗？当然重要。它们会决定你的成功吗？当然不会。当你从制定战略目标转向执行计划时，适应性和速度将决定成功。客户价值驱动你的运营模式。适应性和速度将决定你实现价值目标的有效性。

Are technology costs and efficiency important? Of course. Will they determine your success? Of course not. As you move from creating strategic goals to executing initiatives, adaptability and speed will determine success. Customer value drives your operating model. Adaptability and speed will determine your effectiveness in achieving value goals.

适应性已经得到证实，但速度呢？众所周知，速度会给人带来麻烦。但你如何追求速度才是关键。

The case for adaptability has been made, but what about speed? Speed has been known to get people in trouble. But it is how you pursue speed that makes the difference.

创造客户价值的不是你完成某项任务的速度，而是你完成一系列任务的速度。主要有以下几个方面：周期——从概念到现金——更短的贡献周期——以及每周的软件交付周期。

It is not how fast you perform a certain task, but rather how fast you perform a series of tasks that produces customer value. There are major cycles—concept to cash—shorter contributing cycles— and weekly software delivery cycles.

保持速度和质量的因素是衡量产品持续的价值流。软件交付系统需要一次又一次地以小增量产生价值，而不仅仅是在长期项目结束时。虽然技术质量可能不会引起高管的共鸣，但缩短交付持续价值的周期时间却会引起高管的共鸣。

The factor keeping both speed and quality high is measurement of the continuous flow of value from a product. A software delivery system needs to produce value in small increments time after time, not just at the end of a long project. While technical quality may not resonate with executives, reducing the cycle time to deliver continuous value does.

我在 TW 的部分工作是帮助高管了解技术的意义。例如，我写了一篇关于技术栈复杂性的文章。

Part of my job at TW was to help convey what technology meant for executives. An example was an article on tech stack complexity.

2015 年，我和 Mike Mason（TW 全球技术主管）、Neal Ford（软件架构师和 meme 管理员）共同撰写了一篇题为“技术栈复杂性对高管的影响”的文章，探讨了高管需要了解的一个技术问题。我们撰写了关于过去 10 年中这种复杂性的扩展的文章。我们提出了一系列问题：您监控哪些技术？您尝试过哪些技术？您放弃了哪些技术？您接受哪些技术？十五年前，很少有人预料到云计算、大数据或社交媒体的影响。2005 年，软件技术栈（用于完成特定任务的程序层）可能有 5 个组件。如今，这些堆栈通常超过 15 个组件。我刚开始工作时，技术栈包含 IBM 360 操作系统和 COBOL 编译器。2015 年，堆栈可能包含以下组件：

In 2015, Mike Mason (TW’s global head of technology), Neal Ford (software architect and meme wrangler), and I authored an article titled “Implications of Tech Stack Complexity for Executives” that addressed a technology issue executives needed to understand. We wrote about the expansion of that complexity in just the previous 10 years. We asked a series of questions: Which technologies do you monitor? Which ones do you experiment with? Which ones do you set aside? Which ones do you embrace? Fifteen years ago, few people anticipated the impact of cloud computing or Big Data or social media. In 2005, a software tech stack (layers of programs to accomplish specific tasks) might have 5 components. Today, these stacks often exceed 15 components. When I started, the tech stack contained an IBM 360 operating system and a COBOL compiler. In 2015, the stack might contain the following components:

• 平台：Microsoft Nano Server、Deis、Fastly、Apache Spark 和 Kubernetes

• Platforms: Microsoft Nano Server, Deis, Fastly, Apache Spark, and Kubernetes

• 新工具（每周都会出现）：例如 Docker Toolbox、Gitrob、Polly、Prometheus 和 Sleepy Puppy

• New tools (which pop up every week): for example, Docker Toolbox, Gitrob, Polly, Prometheus, and Sleepy Puppy

• 编程语言和新框架：例如 Nancy、Axon、Frege 和 Traveling Ruby

• Programming languages and new frameworks: for example, Nancy, Axon, Frege, and Traveling Ruby

• 高级技术：Data Lake、Gitflow、Flux 和 NoPSD

• Advanced techniques: Data Lake, Gitflow, Flux, and NoPSD

Tech@Core 意味着像 Mike、Neal 和我在 2015 年撰写的文章需要引起高管的关注，他们需要了解技术堆栈复杂性的后果：单一供应商解决方案已经过时，团队组成和组织结构需要改变，而构建软件交付能力变得越来越困难。

Tech@Core means articles like the one Mike, Neal, and I wrote in 2015 need to be on the radar of executives, who need to understand the ramifications of tech stack complexity: Single vendor solutions are outdated, team composition and organizational structures need to change, and building software delivery capabilities is increasingly difficult.

EDGE 运营模式

EDGE operating model

强大的数字业务战略提供了方向，但 TW 转型专家发现，战略与实际行动之间存在巨大差距。企业在制定战略的过程中投入了大量时间，但随后却难以将其与行动联系起来。我们发现造成这一难题的两个因素是：有效的联系战略和组织结构惯性。

A robust digital business strategy provides direction, but where TW transformation experts found a yawning gap was between strategy and bona fide action. Enterprises lavished time on the process of creating a strategy, but then had difficulty linking it to action. We identified two factors as contributing to this puzzle—an effective strategy for linkage and organizational structure inertia.

在我们开发 EDGE 的早期，一个 TW 团队（我与团队成员进行了交谈，但我自己并不是成员）与一家电信客户合作，使用精益价值树 (LVT；如图 8.3所示) 制定了从战略到行动的流程。12^他们的评估从数字产品总监开始。

Early in our development of EDGE, a TW team (I talked with team members but was not a member myself) worked with a telco client on its strategy-to-action process using a Lean Value Tree (LVT; shown in Figure 8.3).¹² Their assessment started with the director of digital products.

12.该图表和客户故事最初出现在 Highsmith、Luu 和 Robinson (2020) 中。

12. This graphic and client story originally appeared in Highsmith, Luu, and Robinson (2020).

团队（TW 和客户成员）将当前正在进行的工作与业务目标进行了对比，发现目标并没有表明其重要性。例如，“争取 20% 的市场份额”并没有为客户带来任何好处。团队一起将工作重新定义为客户成果。例如，“争取 20% 的市场份额”变成了“让客户能够在一个地方无缝观看直播电视和互联网电视”。

The team (TW and client members) mapped current work in progress against business goals and discovered the goals didn’t indicate their importance. For example, “Drive to 20% market share” didn’t express any benefit for the customer. Together, the team reframed the work into customer outcomes. For instance, “Drive to 20% market share” became “Enable customers to seamlessly view live TV and Internet TV all in one place.”

团队从这次演习中学到了三件事：

The team learned three things from this exercise:

• 通过从客户结果的角度阐明组织目标，可以清楚地了解每项投资的价值以及它对组织的重要性。

• By articulating the organizational goals in terms of customer outcomes, it became really clear what the value of each investment was and why it was important for the organization.

• 通过对所有正在进行的工作进行可视化，他们可以看到最不重要的项目获得了过多的资金。这带来了重新平衡投资组合的机会。

• By visualizing all work in flight, they could see the least important initiatives were receiving too much funding. This led to opportunities to rebalance the portfolio.

• 通过对初始投资组合审查进行时间限制，他们能够证明应用 EDGE 的价值，并与投资组合所有者、业务部门负责人和首席数字官一起建立继续这项工作的案例。

• By time-boxing the initial portfolio review, they were able to demonstrate the value of applying EDGE and build the case for continuing this work with the portfolio owners, business unit leads, and chief digital officer.

最终的问题仍然是投资方向。首先，团队将业务愿景和战略阐述为目标、赌注和计划的 LVT。其次，他们制定了可操作的、以结果为导向的成功衡量标准，这些标准在交付过程展开时（而不是在交付过程结束时）显示进展。第三，他们使用这些成功衡量标准的相对值来确定工作的优先顺序。通过计算相对值来确定工作的优先顺序比传统的（通常是虚假的精确度）投资回报率分析花费的时间更少，并且关注的是客户结果而不是业务收益。

The ultimate question remained where to invest. First, the team articulated the business vision and strategy as a LVT of goals, bets, and initiatives. Second, they developed actionable, outcome-oriented measures of success that indicated progress as the delivery process unfolded, not at the end. Third, they used the relative value of those measures of success to prioritize work. Prioritizing work by calculating relative values takes less time than traditional (and typically false precision) ROI analysis and focuses on customer outcomes rather than business benefits.

LVT 概念中的“树”一词很重要。树的树枝从树干（愿景）中衍生而来。树木是会变化并适应环境条件的生物。LVT 不是放在书桌后面书架上积满灰尘的规划文件。相反，它是领导层对未来的愿景——从树干到树叶——组织中的每个人都可以指着它说：“我们正朝着那个方向前进，我明白为什么。”如果使用得当，这个工具可以缩小战略计划之间的传统差距，让高管能够理解，并影响每天指导业务的每个价值流中的人员的决策。

The word tree in the LVT concept is important. Trees have branches evolving from the trunk (vision). Trees are living things that change and adapt to environmental conditions. An LVT isn’t a planning document that sits on the shelf behind a desk gathering dust. Instead, it is leadership’s vision of the future—from its trunk to its leaves—that everyone in the organization can point to and say, “We are going that way, and I understand why.” When done well, this tool closes the traditional gap between strategic plans, is understood by the executives, and influences the decision making of the people in each value stream who steer the business on a day-to-day basis.

观察数字化组织的转型就像观察多米诺骨牌的连锁反应：一块倒下的多米诺骨牌引发另一块，进而引发另一块，形成无休止的连锁反应。将客户价值作为主要业务目标，并建立可持续实现该目标所需的速度和适应性，将我们引向另一张多米诺骨牌，在 IT 中称为“项目到产品”，在企业中称为“离散到流程”。

WATCHING THE TRANSFORMATION to a digital organization is like watching a chain reaction of dominoes: One falling domino sets off another, which sets off another, in an unending cascade. Embracing customer value as a primary business goal, and establishing speed and adaptability as required for sustainably achieving that goal, lead us to another domino called “project to product” in IT and “discrete to flow” in the enterprise.

通过从客户入手，精益的价值流映射技术帮助组织分析如何有效地交付价值。精益概念从组织的功能视角（营销、制造、会计）转向流程视角（产品从订单到发货的流程）。现代技术（持续交付）和组织协作（DevOps）提供了持续交付应用程序和功能的能力，而不是定期交付。

By starting with customers, the Lean technique of value-stream mapping helped organizations analyze how to deliver value effectively. Lean concepts led from a functional view of the organization (marketing, manufacturing, accounting) to the view of a flow (a product’s flow from order to shipment). Modern technology (continuous delivery) and organizational collaborations (DevOps) provide the capability to deliver applications and features continuously rather than periodically.

产品交付团队负责产品的各个方面——从产品改进的最新想法到维护项目。从传统角度来看，项目包括一系列要实施和交付的功能，以及一个在一定时期内完成这组功能的项目团队。项目完成后，团队解散。大多数组织（包括 IT 和软件公司）都有维护小组来处理小的改进和错误。

A product delivery team owns all aspects of the product—from the newest ideas for product enhancements to maintenance items. From the traditional perspective, projects consisted of a collection of features to be implemented and delivered and a project team assembled to complete the set of features within a period. When the project was completed, the team disbanded. Most organizations—including both IT and software companies—had maintenance groups that handled minor enhancements and bugs.

产品交付团队可能会根据产品需求扩大、缩小或改变规模，但不会像项目团队那样解散。这些产品团队会做出影响产品整个生命周期的优先级决策。他们负责产生连续的价值流并管理端到端的客户体验，从新客户签约到现有客户放弃产品。从本质上讲，产品团队不再负责特定的项目可交付成果，而是负责连续的价值流——因此从以项目为中心的世界观转变为以产品为中心的世界观。

Product delivery teams may expand, contract, or change size depending on product needs, but they don’t disband, as is the case with project teams. These product teams make prioritization decisions affecting the entire life cycle of the product. They are responsible for generating a continuous stream of value and managing the end-to-end customer experience, from a new customer signing up to an existing customer abandoning the product. In essence, product teams became responsible not for a specific project deliverable, but rather for a continuous stream of value—hence the switch from a project-centric view of the world to a product-centric one.

实施数字化战略的企业必须遵循类似的路径。也就是说，他们必须考虑与客户的整体体验，并考虑如何构建一个框架，以持续提供有价值的客户体验，而不是离散的产品销售。

Enterprises implementing a digital strategy must follow a similar path. That is, they must think about their total experience with customers and consider how they can build a framework for continuous delivery of valuable customer experiences rather than discrete product sales.

unFIX 组织模型

The unFIX organization model

转型运营模式需要灵活、动态的组织模式。2010 年，Jurgen Appelo 出版了《管理 3.0：领导 《敏捷开发人员，培养敏捷领导者》是敏捷管理文献中令人耳目一新的补充。Jurgen 曾是一家中型公司的首席信息官，在那里他创立了 Scrum。作为一名中层经理，他对管理角色应该是什么还不太了解，因此他撰写了《管理 3.0》来填补这一空白。

A transforming operating model requires a flexible, dynamic organizational model. In 2010, Jurgen Appelo published Management 3.0: Leading Agile Developers, Developing Agile Leaders, a refreshing addition to the agile management literature. Jurgen had been the CIO of a mid-sized company, where he instituted Scrum. As a middle manager he hadn’t found much about what management’s role should be, so he wrote Management 3.0 to fill the gap.

管理 3.0 框架理论性与实践性兼备。通过一系列研讨会、引人入胜的练习以及同名书籍，Jurgen 向人们展示了如何成为富有同理心的领导者。

The Management 3.0 framework was both theoretical and practical. Through a series of workshops, appealing exercises, and a book by the same title, Jurgen showed people how to become empathetic leaders.

2022 年初，Jurgen 发布了他最新的创业项目 unFIX，这是一种思考组织设计的有机方式。他担心，目前可用的以扩展为导向的敏捷开发方法严重倾向于不支持适应性（或创新）的传统组织结构。

In early 2022, Jurgen released his latest entrepreneurial endeavor—unFIX—as an organic way to think about organizational design. He was concerned the currently available scaling-oriented approaches to agile development leaned hard toward traditional organizational structures that did not support adaptability (or innovation).

unFIX 模型描述了组织数字化转型工作中的一个关键部分。即使您拥有敏捷思维，您如何组织起来以快速适应变化？当然，任何复杂问题的答案都是乐高积木！将 unFIX 视为组织乐高积木，而不是扩展框架。它是一种思考如何有机地发展组织，但仍然能够响应感官输入的广泛变化的模式。

The unFIX model described a key piece in organizations’ digital transformation efforts. Even if you have an agile mindset, how do you organize to rapidly adapt to changes? Of course, the answer to any complicated problem is Legos! Think of unFIX as organizational Legos, rather than as a framework for scaling. It is a pattern for thinking about how to grow an organization organically, but still able to respond to wide variations in sensory input.

图 8.4所示的 unFIX 方法实现了鼓励速度和创新的多功能组织设计。在传统的层级结构和矩阵组织中，速度是不存在的，因为只有自我管理的单位才能在面临危机或机遇时迅速采取行动。unFIX 模型不提供任何流程。相反，它旨在提供组织设计模式。价值流团队负责产品或产品线，而其他类型的团队则为他们提供支持。

The unFIX approach, depicted in Figure 8.4, enables versatile organizational design that encourages speed and innovation. There’s no speed in classical hierarchies and matrix organizations, because only self-managed units can act fast when faced with crises or opportunities. The unFIX model offers no processes. Instead, it aims to provide organizational design patterns. Value stream crews are responsible for products or product lines, while other types of crews support them.

unFIX 的“积木”是团队，其名称包括价值流、能力、基础、经验和治理。每个团队都有一名队长。小型组织或项目可能只需要几种类型的团队——基础、价值流、治理。随着组织或项目的发展，可以添加更多专业团队。

The Legos of unFIX are crews with names such as Value Stream, Capability, Base, Experience, and Governance. Each crew has a captain. Small organizations or projects might need only a few crew types—Base, Value Stream, Governance. As the organizations or projects grow, additional specialized crews can be added.

我想重申这一点：unFIX 不是流程指南；它是组织结构指南。同一组织中的两个价值流团队可以使用两种不同的流程——看板和 Scrum。两个不同的治理团队可能会使用不同的投资组合优先级排序方法——或者相同的方法。

I want to reiterate this point: unFIX is not a process guide; it is an organizational structure guide. Two Value Stream crews in the same organization could use two different processes—Kanban and Scrum. Two different Governance crews might use different portfolio prioritization methods—or the same one.

两种类型的扩展很少被区分：在大型组织中实施敏捷实践和为大型产品（例如自动驾驶汽车产品）实施敏捷实践。然而，每种方法都需要自己的组织结构。unFIX 可以处理这两种情况。敏捷方法长期以来一直专注于建立价值驱动、协作、自组织、自给自足的团队。现在我们有了一份指南，用于组建具有相同特征的组织。

Two categories of scaling are rarely differentiated: implementing agile practices across a large organization and implementing agile practices for a large product (an autonomous vehicle product, for example). Yet each of these requires its own organizational structure. unFIX can handle both. Agile methods have long focused on building value-driven, collaborative, self-organizing, self-sufficient teams. Now we have a guide to putting together organizations that incorporate the same characteristics.

我与 Jurgen Appelo 就他在 2022 年中期的工作进行了交谈^。13

I HAD A CONVERSATION with Jurgen Appelo about his work in mid-2022.¹³

13.您可以访问Jurgen的网站：https://unfix.com/。

13. You can visit Jurgen’s website at https://unfix.com/.

您在软件开发方面的背景是什么？

What was your background in software development?

我毕业于计算机科学系，获得了软件工程学位。虽然我喜欢编程，但我的兴趣还包括更广泛的金融、营销和一般商业主题。在 20 世纪 90 年代，我发现需要针对新兴软件开发主题的课程，因此我成立了一家开发和提供课件的公司。我很容易感到无聊，所以我喜欢开发材料，但不喜欢一次又一次地讲授相同的课程。当我开发新课程时，我开始聘请其他人来教授这些课程。

I graduated with a degree in software engineering within a computer science department. While I enjoyed programming, my interests included the broader realms of finance, marketing, and general business topics. In the 1990s, I saw a need for courses targeting emerging software development topics, so I founded a company that developed and presented courseware. I get bored easily, so I enjoyed developing the material, but not so much delivering the same course time after time. I began engaging others to teach the courses as I developed new ones.

接下来发生了什么？

What came next?

2000 年，我成为一家中型公司的首席信息官，任职 10 年。我们一开始只有 31 名员工，在我离开之前，员工人数增加到了 200 人。我读过所有敏捷书籍，包括您的书，并在我们部门实施了 Scrum。中层管理的敏捷主题似乎是“让他们远离”，这似乎对我的职位不尊重，所以我开始思考经理在敏捷部门中的角色是什么。这种思考促使我在 2010 年出版了《管理 3.0》。Mike Cohn 很早就知道了我的书，并邀请我将其发表在他的签名系列中，我对此欣喜若狂。

In 2000, I became the CIO of a mid-sized company for 10 years. We started with 31 people, and it grew to 200 before I left. I had been reading all the agile books, including yours, and implemented Scrum in our department. The agile theme for middle management seemed to be “keep them out of the way,” which seemed disrespectful to my position, so I started thinking about what managers’ role was in an agile department. This thinking resulted in publishing Management 3.0 in 2010. Somehow Mike Cohn learned about my book early on and invited me to publish it in his signature series, which I was ecstatic to do.

unFIX 组织模型是如何演变的？

How did the unFIX organizational model evolve?

正如我之前提到的，我很容易感到无聊，所以我卖掉了管理 3.0 研讨会业务，开始寻找下一个大项目。我研究了使用游戏化技术进行学习，并研究了组织设计。与 [管理] 3.0 的发展类似，组织试图扩大敏捷性，但 SAFe 等可用框架过于结构化。随着组织规模的扩大，它们失去了适应性——而这正是敏捷的核心特征。unFIX 解决了这个问题。

As I mentioned earlier, I get bored easily, so I sold the Management 3.0 workshop business and began casting around for the next big thing. I investigated using gamification techniques for learning and looked at organizational design. Similarly, to the evolution of [Management] 3.0, organizations were attempting to scale agility, but the available frameworks like SAFe were too structured. As organizations scaled, they lost adaptability—the very characteristic that is the core of agile. unFIX fixes that.

unFIX 这个名字是怎么来的？

Where did the name unFIX come from?

这是一个有趣的问题。虽然我并不热衷于 SAFe，但我很欣赏他们的营销。这个名字很好地传达了他们的使命——保持安全。我想要一个能传达正确信号的名字，一种充满活力、创新、探索的心态。名称中的“ix”部分代表创新和经验。我想要这样的想法：你可以通过系统地解除组织的部分来“修复”组织。[在图 8.4中]，颜色和笑脸也很重要。它们传达了一个严肃话题的不严肃性。

That’s an interesting question. While I’m not wild about SAFe, I admire their marketing. The name does well convey their mission—to stay safe. I wanted a name that would convey the right signal, a dynamic, innovative, exploring mindset. The “ix” parts of the name represent innovation and experience. I wanted the idea you could “fix” an organization by systematically unFIXing parts of it. [In Figure 8.4], the colors, and smiley faces are important also. They convey the unseriousness of a serious topic.

您希望 unFIX 去往何处？

Where would you like unFIX to go?

我希望 unFIX 能成为 SAFe 和 Spotify 等组织框架的替代方案。Holacracy 有时会被提及作为一种替代方案，但对大多数人来说，它有点太过遥远了——而且这个名字也没什么帮助。我想为组织提供组织乐高积木，以便他们能够快速适应。我想让组织尽可能保持简单。我想从最简单的事情开始，然后根据需要添加，但不要添加太多，以免干扰创新和适应性。SAFe 采取了相反的方法，添加了太多主题，然后要求用户“删除”他们不需要的内容 [还记得 RUP 吗？]。

I hope that unFIX becomes an alternative to frameworks like SAFe and Spotify for organizations. Holacracy is sometimes mentioned as an alternative, but it’s a little far out there for most—and the name doesn’t help. I want to give organizations their organizational Lego blocks so they can adapt quickly. I want to keep this as simple as possible for an organization. I want to start with the simplest thing possible and then add as necessary but not enough to interfere with innovation and adaptability. SAFe takes the opposite approach, adding too many topics and then asking users to “take away” what they don’t need [Remember RUP?].

敏捷团队要想取得成功，其成员需要具备敏捷思维、敏捷流程以及适当的技能和经验。对于拥有多个团队的组织，您需要添加“比刚好足够的结构稍少一点”的东西。Jurgen 的 unFIX 模型提供了一种实现这一目标的构建块方法。您需要足够的结构来在混乱的边缘保持平衡，但仅此而已。虽然我没有使用 unFIX 的第一手经验，但我已经阅读了 Jurgen 的文章并与他进行了足够多的交流，我认为他走在正确的道路上。

For an agile team to succeed, its members need an agile mindset, an agile process, and appropriate skills and experience. For organizations with multiple teams, you need to add “a little bit less than just enough structure.” Jurgen’s unFIX model offers a building-blocks way to accomplish that. You need enough structure to balance on the edge of chaos, but no more. Although I don’t have firsthand experience with unFIX, I’ve read and talked enough with Jurgen to think he is on the right track.

富有同情心和适应能力的领导力

Empathetic and adaptive leadership

多年来，不断发展的管理理论对软件开发产生了诸多影响。敏捷运动为后来的变革提供了鼓励和领导力。由于这不是一本管理书籍，我挑选了一些引领潮流的声音。正如你所看到的，我们正在谨慎地从传统的命令控制、X 理论、优化管理观点转变为一种富有同理心的现代管理观点，这种观点融合了领导协作、Y 理论、unFIX、同理心、敏捷性和适应性领导。

Evolving management theories have had numerous impacts on software development throughout the years. The agile movement provided encouragement and leadership for those later changes. Since this is not a management book, I have picked out a few voices instrumental in leading the way. As you will see, we are cautiously making the transition from a traditional command-control, Theory X, optimizing view of management to an empathetic, modern one incorporating leadership-collaboration, Theory Y, unFIX, empathy, agility, and adaptive leadership.

使用工业时代的组织结构或文化不会发生转型。丽塔·麦格拉斯 (2014) 将这个新的管理时代定义为基于同理心的时代：

Transformation isn’t going to happen using organizational structures or culture from the industrial age. Rita McGrath (2014) identifies this new management age as one based on empathy:

其他人已经感觉到，我们已经准备好迎接商业思维和实践的新时代。在我看来，这意味着要弄清楚当工作是通过网络而不是通过个人完成时，管理是什么样子的。通过指挥线，当“工作”本身带有情感色彩，当个别管理者负责为与他们一起工作的人创建社区时。如果今天对管理者的要求是同理心（不仅仅是执行力，不仅仅是专业知识），那么我们必须问：哪些新角色和组织结构有意义，绩效管理应该如何进行？领导者需要什么才能发挥“支柱”的作用，下一代管理者应该如何接受教育？所有关于管理的问题都重新摆在桌面上——我们无法很快找到答案。

Others have sensed that we are ready for a new era of business thinking and practice. From my perspective, this would mean figuring out what management looks like when work is done through networks rather than through lines of command, when “work” itself is tinged with emotions, and when individual managers are responsible for creating communities for those who work with them. If what is demanded of managers today is empathy (more than execution, more than expertise), then we must ask: What new roles and organizational structures make sense, and how should performance management be approached? What does it take for a leader to function as a “pillar” and how should the next generation of managers be taught? All the questions about management are back on the table—and we can’t find the answers soon enough.

Tracy Bower (2021) 写道：“同理心有助于建立积极的关系和组织文化，也能推动成果。同理心可能不是一项全新的技能，但它的重要性达到了一个新的水平，而最新的研究尤其清楚地表明，同理心是现在和未来工作中需要发展和展示的领导能力。” 一个有同理心的领导者可以设身处地为他人着想，深刻理解他们的想法、恐惧和成功。我在 2002 年采访 Kent Beck 时就举了一个例子，说明了同理心领导者的一个例子^。14

Tracy Bower (2021) writes, “Empathy contributes to positive relationships and organizational cultures, and it also drives results. Empathy may not be a brand new skill, but it has a new level of importance, and the fresh research makes it especially clear how empathy is the leadership competency to develop and demonstrate now and in the future of work.” An empathetic leader can put themself in another’s shoes, providing a deep understanding of their thoughts, fears, and triumphs. An example of an empathetic leader was illustrated by an interview I had with Kent Beck in 2002.¹⁴

14.本节是我在《敏捷软件开发生态系统》一书中对 Kent 的采访的编辑版本（Highsmith，2002 年）。

14. This section is an edited version of the interview with Kent in my Agile Software Development Ecosystems book (Highsmith, 2002).

您为什么对复杂自适应系统（CAS）理论感兴趣？

Why did you become interested in complex adaptive systems (CAS) theory?

复杂自适应系统 (CAS) 理论对你应该如何在这个世界上行事有一个相当简单的解释。找到这套规则，然后按照它们采取行动，衡量结果，并调整这套规则。当你真正接受这一点时，你会感到非常自由。你不必监督一切；你不必做出所有的技术决策。事实上，作为一名领导者，你做出的技术决策越多，你就越会破坏团队的活力。

Complex adaptive systems (CAS) theory has quite a simple explanation about how you ought to behave in the world. Find this set of rules and then act on them, measure the results, and tweak the set of rules. It’s very liberating when you really take that in. You don’t have to oversee everything; you don’t have to make all the technical decisions. In fact, to the degree to which as a leader you are making technical decisions, you are screwing up the dynamic of the team.

但有时人们希望你做出决定，而你必须拒绝。

But sometimes people want you to make decisions, and you must push back.

哦，当然！有人走进你的办公室，请你做决定。你问他们，“你认为哪种选择最好？”他们经常回答说他们不知道。“好吧，如果你不知道，也许我们最好两种都试一下，然后接受结果。”如果他们不想花那么多时间，鼓励他们只选一个。

Oh, absolutely! Someone comes into your office and asks you for a decision. You ask them, “Which alternative do you think is the best?” They often respond that they don’t know. “Well, if you don’t know, maybe we’d better try them both and take the hit.” When they don’t want to take that much time, encourage them to just pick one.

在这种情况下，控制导向型经理通常会利用人们不愿做决定的心理来支持他们的观点：经理必须做决定。推迟决策有助于每个人学习新的工作方式。

In these situations, a control-oriented manager will often use people’s reluctance to make decisions to bolster their view managers must make the decisions. Pushing out decision making helps everyone learn a new way of operating.

后来我加入了克莱斯勒的 C3 项目，我尽量少插手。我不会做任何技术决定。

Then came the C3 project at Chrysler, where I tried to be much more hands off. I wasn’t going to make a single technical decision.

您想尝试创建正确的环境吗？

You were trying to create the right kind of environment?

是的，罗恩·杰弗里斯和我试图设定初始条件，然后对其进行调整。没有英雄主义，没有肯特骑着白马，这对我来说是价值体系的重大转变。我以自己是这个领域最伟大的物品大师而自豪。我不得不故意放弃这一点，只是说这不会让我变得有价值。

Yes, Ron [Jeffries] and I were trying to set up the initial conditions and then tweak them. No heroics, no Kent riding in on a white horse, which was quite a switch in value systems for me. I prided myself on being the biggest object guru on the block. I had to deliberately give that up and just say that’s not what’s going to make me valuable.

我发现这种管理方法的一个问题是，成功在人们看来往往几乎是偶然的。

I’ve found that one of the problems with this approach to management is success often seems almost accidental to people.

我遇到过最好的经理，他在斯坦福线性加速器实验室工作。我在控制室工作。这家伙把所有时间都花在了制造 Heathkits 上。15^每个人都抱怨他有多懒，为什么他不做这做那。但一切都总是按时完成；如果你需要零件，他们就在那里。个性冲突可以立即解决。我一直希望自己不是 20 岁，这样我就能体会到这家伙的绝对大师风范。他让一切都运行得非常顺利。这就是我作为教练的审美观。如果我把每件事都做得完美无缺，那么我的贡献对团队来说是完全看不见的。团队会说，“我们做到了。”

The best manager I ever had was at the Stanford linear accelerator lab. I worked in the control room. This guy spent all his time building Heathkits.¹⁵ Everybody complained about how lazy he was and why he didn’t do this or that. But everything was always on time; if you needed parts, they were there. Personality clashes got resolved instantly. I’ve always wished I wasn’t 20 years old when it happened so I could appreciate that this guy was absolutely masterful. He kept everything running absolutely smoothly. So that’s my aesthetic as a coach. If I do everything perfectly, then my contribution is totally invisible to the team. The team says, “We did this.”

15.对于 20 世纪 70 年代后开始生活的人来说，这些是人们组装的电子产品套件，比如收音机。

15. For those who started life after the 1970s, these are electronic product kits, like radios, that one assembled.

这是一件很难的事情。如果你认为领导者是泰迪·罗斯福冲上圣胡安山，在枪林弹雨中勇敢面对死亡，那么像这样的运作是不可能实现的。但如果你的团队以这种自组织的方式运作，让某人注入这种领导力就会造成混乱。

That’s a hard thing. If your view of a leader is Teddy Roosevelt charging up San Juan Hill, braving death with the bullets flying around, then it’s just impossible to operate like this. But if you have a team that’s operating in this self-organizing fashion, it’s disorganizing to have someone inject that kind of leadership.

肯特提出了一个很有说服力的观点——泰迪·罗斯福在圣胡安山上冲锋陷阵的风格与他那位看不见却成功的管理者风格之间的区别再大不过了。最大的问题是，哪一个更好？如果存在一种“最佳”领导风格，为什么它不明显？为什么我们继续有大量关于领导力的书籍？实际上没有一种最佳风格：管理者需要根据一套基本价值观，根据情况调整他们的风格。

Kent makes a telling point—the difference between Teddy Roosevelt charging up San Juan Hill versus his invisible, but successful manager’s style couldn’t be greater. The big question, which is better? If there is a “best” leadership style, why isn’t it obvious? Why do we continue to have a cascade of leadership books? There isn’t really one best style: Managers need to adapt their style to conditions based on an underlying set of values.

期间观察

Period observations

除了在组织中实施敏捷方法之外，数字化转型时期还探索了成为数字化企业意味着什么，就像从俗话说的“跳出油锅又跳进火里”一样。我们从与二级和三级领导合作，到与 CIO、CEO 和麦肯锡级战略咨询公司合作。

Moving beyond implementing agile methodologies in an organization, the Digital Transformation period explored what becoming a digital enterprise meant, much like jumping from the proverbial “frying pan into the fire.” We went from working with second- and third-level leaders to working with CIOs, CEOs, and McKinsey-level strategic consulting firms.

在本世纪初，首席执行官们对 ICT 及其数字企业战略的兴趣日益浓厚。企业高管制定了数字战略，但发现从战略到运营模式的转变不够顺利。回顾以往的 ICT 转型，他们明确指出，现在是时候大胆创新、打破常规了。EDGE、unFIX 和 SPARKS（Augustine，“Business Agility SPARKS”）就是为了满足这一需求而开发的——旨在提出超越安全和传统的方法和方法论。

In the early years of the decade, CEOs intensified their interest in ICT and their digital enterprise strategies. Enterprise executives developed digital strategies but found their transition from strategy to operating models lacking. Looking back at previous ICT transformations, they clearly pointed out that it was time to be adventurous and nonconformist. EDGE, unFIX, and SPARKS (Augustine, “Business Agility SPARKS”) were developed in response to that need—to present methods and methodologies beyond the safe and traditional.

如今，企业应该寻求数字化转型，而不是实现数字化转型。转型表示某个阶段的完成，而转型则表示不断演变。六十多年来，变革的速度和类型不断升级，要求组织通过解决以下领域不断适应：

Enterprises today should be seeking to become digital transforming rather than to achieve digital transformation. Transformation indicates completion of a stage, whereas transforming suggests a constant state of becoming. More than six decades of escalating rates, and types, of change have required organizations to constantly adapt by addressing the following areas:

• 成功的衡量标准：绩效衡量标准可以推动或限制变革。

• Measures of success: Performance measures can drive or restrict change.

• Tech@Core：数字化需要商业技术合作。

• Tech@Core: Being digital demands a business technology partnership.

• 运营模式：将战略与行动联系起来。

• Operating model: Linking strategy to action.

• 组织模型：创建一个可快速调整的结构。

• Organizational model: Creating a quickly malleable structure.

• 同理心管理：适合数字时代的管理。

• Empathetic management: Management suited for the digital era.

这五个理念面向行动，面向“敏捷实施”。第 9 章确定了可衡量（可评估）的行动，这些行动表明“​​敏捷”对领导者意味着什么。

These five ideas are oriented towards action, to “doing agile.” Chapter 9 identifies measurable (assessable) actions that indicate what “being agile” means for leaders.

在减少了一段时间的旅行和工作时间后，我于 2021 年初从 Thoughtworks 退休。但随着我继续与前同事互动，我现在理解了其他 TW 校友的俏皮话，“一旦成为 Thoughtworker，永远都是 Thoughtworker”。节奏继续，仍然很有趣。

After reducing my travel and work hours for a time, I retired from Thoughtworks early in 2021. But I now understand the quip of other TW alumni, “Once a Thoughtworker, always a Thoughtworker,” as I continue to interact with former coworkers. The beat goes on, and it is still fun.

为什么是历史？

Why history?

温斯顿·丘吉尔的历史知识（他撰写的六卷本二战史获得了诺贝尔奖）塑造了英国的二战战略。乔治·巴顿将军热衷于研究从伯罗奔尼撒战争到第一次世界大战的军事史；他以著名的历史战役为背景来描述二战中的战役。对世界史和军事史的了解为巴顿和丘吉尔提供了一个历史框架，使他们能够根据这些历史框架来决定当前的行动方针。

Winston Churchill’s knowledge of history (his six-volume history of World War II won a Nobel Prize) shaped Great Britain’s World War II strategy. General George Patton was an avid student of military history from the Peloponnesian War to World War I; he framed his World War II battles in the context of famous historical ones. Knowledge of world and military history gave Patton and Churchill a historical framework with which to make decisions about their present courses of action.

同样，著名历史学家沃尔特·艾萨克森 (Walter Isaacson) 也对两项既给未来带来希望又带来威胁的关键技术的历史进行了解读——信息技术和基因拼接。艾萨克森著有《史蒂夫·乔布斯》 (2011) 和《密码破译者：詹妮弗·杜德娜、基因编辑和人类的未来》 (2021)。如果没有关于信息和基因拼接技术以及引领这些技术的先驱人物的历史知识，那么为我们混乱的未来做准备将是肤浅的。

Similarly, Walter Isaacson, a well-known historian, offers an understanding of the history of two critical technologies that offer both promise and threat in the future—information technology and gene splicing. Isaacson authored both Steve Jobs (2011) and The Code Breaker: Jennifer Doudna, Gene Editing, and the Future of the Human Race (2021). Preparing for our chaotic future would be shallow without this kind of historical knowledge about information and gene splicing technologies, and the pioneering individuals who spearheaded them.

《连线》杂志前主编凯文·凯利在他的网站上发表了一篇名为《如何走向未来》的文章，他在文中宣称：“大多数未来学家实际上都在预测现在。”如果我们处于经济、政治和健康平衡时期，那么试图预测未来似乎是徒劳的。我们需要从预测和规划未来转向构建一个平台，使我们能够适应任何情况。软件开发的演变就是该平台的一部分。历史为我们提供的不仅仅是日期、名称和地点；它还帮助我们理解事件发生的原因。反过来，这为我们提供了更好地理解现在和在未来做出更明智决策的可能性。

Kevin Kelley, former editor of Wired magazine, published an article on his website called “How to Future,” in which he declared, “Most futurists are really predicting the present.” If we are in a period of economic, political, and health punctuated equilibrium, then trying to predict the future seems futile. We need to move from predicting and planning for the future, to building a platform that enables us to adapt to whatever happens. The evolution of software development forms part of that platform. History offers us more than dates, names, and places; it also helps us understand why events transpired as they did. In turn, this offers us the possibility of better understanding our present and making better-informed decisions in the future.

那么，我们从 60 年的软件开发历程中学到了什么？那段时间发生了什么？我们对创造这些发展的先驱者有何了解？了解这些事件和先驱者如何帮助我们为未来做好准备？当我研究和撰写我的过去时，我对自己有何了解？

So, what did we learn from our journey through six decades of software development? What happened during that time? What did we learn about the pioneers who created those developments? How might an understanding of those events and the pioneers help prepare us for the future? What did I learn about myself as I researched and wrote about my past?

写这本书迫使我回忆过去的点滴，并试图将它们融入背景中。为未来做准备要求我们扩展敏捷思维，而不仅仅是敏捷方法和方法论。改变个人和组织的思维方式无法用简单的方法和固定的答案来解释。我的感觉是，冒险精神和不墨守成规有助于我们应对这些挑战。

Writing this book forced me to remember pieces of the past and attempt to put them into context. Preparing for the future challenges us to scale an agility mindset, not simply agile methods and methodologies. Changing individual and organizational mindsets defies simple approaches and canned answers. My sense is that adventurousness and nonconformity helps us meet these challenges.

那么那些引领软件开发进步的人呢？写这本书的乐趣之一就是与十年或三十年没有联系的同事重新取得联系。了解他们的生活早就应该了，他们对软件开发的想法，无论是当时还是现在，都是无价之宝。

What about the people who pioneered software development advances? One of my joys in writing this book was reconnecting with colleagues I hadn’t talked with in a decade or three. Catching up on their lives was long overdue, and their thoughts about software development, then and now, were invaluable.

软件开发的历史坎坷不平，但也令人兴奋。但首先，敏捷开发会持续下去吗？

The history of software development is bumpy, not smooth, which makes it exciting. But first, is agile development here to stay?

敏捷与敏捷

Agile and agility

越来越多的人现在问：“敏捷是否已经走到尽头？是否到了做出改变的时候？” ³我的回答是 (1)“这取决于你对敏捷的定义”和 (2)“永远都需要做出改变。”事实上，我们需要从三个方面来询问敏捷开发的未来：“现有的敏捷方法是否已经过时？敏捷方法论是否已经过时？敏捷思维是否已经过时？”敏捷是从结构化时代的方法发展而来的，因为业务问题和技术发生了变化。互联网技术催生了需要速度和灵活性的新业务模式。关于敏捷开发是否过时的问题也必须在时代背景下进行评估。例如，在输入到输出时间在 12 到 24 小时之间的狂野西部时代，敏捷实践是否有效？

A growing contingent is now asking, “Has agile run its course? Is it time for a change?”³ My answers are (1) “It depends on your definition of agile” and (2) “It’s always time for a change.” In truth, we need to ask the question about agile development’s future in three ways: “Have existing agile methods become obsolete? Have agile methodologies become obsolete? Have agile mindsets become obsolete?” Agile evolved from Structured-era approaches because business problems and technology changed. Technology in the form of the Internet spurred new business models that demanded speed and flexibility. The questions about the obsolescence of agile development must also be evaluated within the context of the times. For example, would agile practices have worked in the Wild West era when input-to-output times were in the range of 12–24 hours?

3.例如，阅读Kurt Cagle（2019）的《敏捷的终结》。

3. For example, read “The End of Agile” by Kurt Cagle (2019).

鉴于技术和软件开发平台的进步，第一个问题的答案相对简单。一些敏捷方法仍然适用；其他方法则不会。考虑一下 Larry Constantine 的结构化时代耦合和内聚概念，35 年后它们仍然适用。自动化可能会加速其他方法走向无关紧要的旅程。假设《重构：改进现有代码的设计》（2018 年）的作者 Martin Fowler 创建了一个自动重构工具，那么后代开发人员可能不再需要学习手动重构。随着时代背景的变化，个别方法将出现和消亡，可能不会被认定为敏捷方法。

The answer to the first question is relatively simple, given the advances in technology and software development platforms. Some agile methods will still be relevant; others won’t. Consider Larry Constantine’s Structured-era concepts of coupling and cohesion, which are still relevant 35 years later. Automation may hasten other methods’ journey to irrelevance. Suppose Martin Fowler, author of Refactoring: Improving the Design of Existing Code (2018), created an automated refactoring tool—then subsequent generations of developers might no longer need to learn manual refactoring. Individual methods will arise and retire as the context of the times changes and may not be identified as agile methods.

方法论既能解决业务问题，又能应对技术创新。有人会想出一种新方法论，将现有的敏捷方法和应对技术进步的新方法结合起来。他们可能会发明一种新名字的流派，并说：“Excalibur 方法论是新的、现代的，可以用敏捷解决所有问题。”您可以利用最新的虚拟现实和人工智能技术更快地交付高质量的软件。”也许交付速度会如此之快，以至于 Ken Orr 的“一分钟方法论”（1990 年）将重新流行起来。这会发生，打赌吧。正如敏捷主义者反复强调结构化和瀑布式开发的缺点一样，Excalibur 的支持者也会反复强调敏捷的缺点。

Methodologies respond to both business problems and technology innovation. Someone will come up with a new methodology combining both existing agile methods and new methods that respond to technological advances. They may invent a genre with a new name and say, “The Excalibur Methodology is new, modern, and solves all the problems with agile. You can utilize the latest in virtual reality and artificial intelligence to deliver high-quality software much faster.” Maybe delivery will be so fast that Ken Orr’s One Minute Methodology (1990) will come back into vogue. This will happen, bet on it. And just as agilists harped on the shortcomings of structured and waterfall development, so Excalibur proponents will harp on agile’s shortcomings.

值得重复第三章中的一句话：当我们回顾软件开发的演变和革命时，我们需要记住，方法、方法论和思维方式都是为了解决每个时代的问题而演变的，无论是受到当时技术的支持还是限制。

It is worth repeating a statement made in Chapter 3: As we traverse the evolution and revolution of software development, we need to remember that methods, methodologies, and mindsets all evolved to solve the problems of each era, both enabled and constrained by the technology of that time.

这给我们留下了最后一个问题，“敏捷思维是否已经过时了？”，也可以表述为“敏捷性是否已经过时了？”在本书涵盖的六十年时间跨度中，您何时注意到世界、技术、商业、文化、音乐的变化速度减慢了？从我的角度来看，变化一直在不断螺旋式上升，不仅是线性的，而且接近指数级。我不会说对敏捷、适应性思维的需求永远不会改变，但我只是认为在可预见的未来它不会发生。

That leaves us with the last question, “Have agile mindsets become obsolete?”, which might also be phrased as “Has agility become obsolete?” Over the six-decade span of time covered by this book, when have you noticed the rate of change in the world, in technology, in business, in culture, in music, slow down? From my perspective, change has spiraled constantly upward, not only linearly, but bordering on exponentially. I won’t say the need for an agile, adaptive mindset will never change, but I just don’t see it happening in the foreseeable future.

对于试图变得敏捷的组织和个人，从这段历史中可以得出一个结论：目标应该是敏捷，而不是敏捷本身。敏捷是一种思维方式，敏捷是一种方法。如果不能做出这种区分，组织就只能使用规范的敏捷方法，而拥抱敏捷的领导者最有可能在未来蓬勃发展。考虑到气候变化、地缘政治动荡、新冠肺炎和俄乌战争等未知和不可知因素的强大组合，我们可能正在进入一个达尔文“适者生存”法则让位于“幸运者生存”法则的时期，在这种情况下，敏捷可能是我们仅存的战略优势。

For organizations and individuals trying to become agile, one conclusion from this history is that agility, not agile, should be the goal. Agility is a mindset; agile is a type of methodology. Failure to make this differentiation has left organizations with prescriptive agile methodologies, while leaders who embrace agility have the best chance of thriving in the future. Given the unknown and unknowable from the potent combination of climate change, geopolitical unrest, COVID-19, and the Russia–Ukraine war, we may be entering a period in which Darwin’s law of “survival of the fittest” gives way to “survival of the luckiest,” in which case agility may be our only remaining strategic advantage.

实现敏捷思维很难，原因有二：很难做到，而且定义不明确。没有人能轻易改变根深蒂固的思维模式，如果他们这样做了，这些模式就毫无用处了。改变需要的不仅仅是一天的研讨会。同事 Gil Broza 写了一本关于敏捷思维的书，他说：“即使组织和管理者打算以正确的思维方式开始他们的敏捷之旅，许多人也没有意识到转变的规模和复杂性”（Broza，2015 年，第 xix 页）。

ACHIEVING AN AGILE mindset is difficult for two reasons: It’s hard to do, and it’s ill defined. No one changes deeply held mental models easily and if they did, the models wouldn’t be useful. Change takes more than a one-day workshop. Colleague Gil Broza, who wrote a book on the agile mindset, says, “Even when organizations and managers intend to start their Agile journey with the right mind-set, many don’t realize the magnitude and complexity of the transformation” (Broza, 2015, p. xix).

史蒂夫·丹宁 (Steve Denning) 在最近的《福布斯》在线文章中尝试了这种观点：

Steve Denning took a stab at this mindset in a recent Forbes online article:

敏捷思维更多地是实践者而非理论家的属性。它比理论哲学更务实、更注重行动。它超越了一套信念，成为诊断的工具和行动的基础。（Denning，2019）

The Agile mindset is an attribute of practitioners more than theorists. It is pragmatic and action-oriented more than a theoretical philosophy. It goes beyond a set of beliefs and becomes a tool for diagnosis and the basis for action. (Denning, 2019)

尽管史蒂夫的描述很好，但我认为它不可行。

While Steve’s description is fine, I don’t find it actionable.

心态一直是心理学家们感兴趣的话题，例如《心态：成功的新心理学》（2006 年）一书的作者 Carol S. Dweck。Dweck 提出存在两种心态——固定心态和成长心态，并解释了每种心态如何影响我们学习、感知世界和做出决策的方式。

Mindset has been a topic of interest to psychologists like Carol S. Dweck, author of Mindset: The New Psychology of Success (2006). Dweck proposes that two mindsets—fixed and growth—exist, and explains how each one affects the way we learn, perceive the world, and make decisions.

心态也可以看作是一种信念体系。如果你相信道格拉斯·麦格雷戈的“X 理论”，该理论认为人们本质上是懒惰的，需要管理者“激励”，那么这种信念就会渗透到你处理人事问题的方法中。相反，如果你相信人们受到丹·平克的“目标、精通和自主”的激励，那么你处理人事问题的方法就会完全不同。

Mindset can also be viewed as a system of beliefs. If you believe in Douglas McGregor’s Theory X, which assumes people are basically lazy and need to be “motivated” by managers, then that belief permeates your approach to personnel issues. Conversely, if you believe people are motivated by Dan Pink’s purpose, mastery, and autonomy, then your approach to people management will be entirely different.

在寻找一种更简单、更可行的心态评估方法时，我回想起历史是由人创造的，因此要了解历史，就必须了解那些人。但是你需要了解他们什么呢？为了评估敏捷性，我将人们的行为分为以下几类，而不是使用难以捉摸的个性特征：

Searching for a simpler, actionable assessment of mindset, I recalled that history is made by people, so to understand history, you have to understand those people. But what do you need to understand about them? To evaluate agility, rather than use elusive personality traits, I categorize people’s actions:

勇于冒险：

Adventurous:

• 在未知领域设定勇敢的目标。

• Sets courageous goals into uncharted territory.

• 接受风险但不会轻率。

• Accepts risks but isn’t imprudent.

• 在条件不明确时可以采取行动。

• Can act when conditions are ambiguous.

• 克服失望和恐惧。

• Overcomes disappointment and fear.

不墨守成规者：

Nonconformist:

• 挑战社会、文化或工作场所规范。

• Challenges social, cultural, or workplace norms.

• 即使超出常规，也要保持真实的自我。

• Authentic to oneself even when outside the norm.

适应性：

Adaptable:

• 感知环境输入并过滤相关输入。

• Senses environmental inputs and filters the relevant ones.

• 通过在“混乱边缘”保持平衡来创造创新的组织反应。

• Creates innovative organizational responses, by balancing at the “edge of chaos”.

• 迅速采取行动、进行调整、转变或放弃举措。

• Quickly acts, adjusts, pivots, or abandons initiatives.

了解个人在这些领域中的行为有助于评估他们的敏捷性。你可以观察这些行为，但它们是不可测量的，只能评估。攀登也类似。关于路线、何时前进和何时折返的决定是可以评估的，但它们是不可测量的。关于导致攀登灾难和成功的决定，已经写了很多书。攀登者必须明智地选择他们的攀登伙伴——这种评估类似于评估任何级别的团队成员的个人身份。

Learning about individuals’ actions in each of these areas helps assess their agility. You can observe these actions, but they are not measurable, only assessable. Climbing is similar. Decisions about routes, when to move on and when to turn back, are assessable, but they are not measurable. Entire books have been written about decisions that led to climbing disasters and successes. Climbers must select their climbing partners wisely—an assessment similar to assessing individuals for team membership at any level.

工程师、开发人员、业务分析师、业务系统协调员、软件开发经理、会计主管、销售和营销副总裁、咨询副总裁、产品经理、敏捷项目管理总监、执行顾问。在我的职业生涯中，我担任过这些职位。回顾过去 60 年，我意识到所有这些职位都有一个共同点：每个职位都很难，极其难。它们都以不同的方式变得困难——有些是技术上的，有些是人际上的，有些是政治上的。

ENGINEER, DEVELOPER, business analyst, business systems coordinator, software development manager, accounting supervisor, vice president of sales and marketing, vice president of consulting, product manager, director of agile project management, executive consultant. At some point in my career, I’ve held each of these positions. As I look back over six decades, I realized there was a single element common to all these positions: Each was hard, extremely hard. They were all difficult in different ways—some technical, some interpersonal, and some political.

我之所以提到这一点，是因为我们很容易贬低他人。开发人员很容易贬低产品经理，开发经理很容易贬低项目经理，几乎每个人都很容易贬低高级管理层。虽然这种倾向可能是自然的，但它没有帮助。正如波特兰抵押贷款公司的故事所指出的那样，组建跨职能团队可以为团队带来多样性，但这些团队可能会彼此孤立，导致沟通不畅。我发现问题在于不了解其他人实际上在做什么。

I bring this up because of the ease with which we tend to disparage others. It’s easy for developers to disparage product managers, development managers to disparage project managers, and virtually everyone to disparage senior management. While this tendency may be natural, it’s not helpful. As pointed out in the Portland Mortgage company story, forming cross-functional teams can bring diversity to a team, but those teams can then become isolated from each other, leading to miscommunication. I’ve found the issue revolves around not understanding what others actually do.

让软件开发人员扮演销售代表的角色，或让产品经理担任高管角色，看看态度变化有多快。必须扮演另一个角色可以迅速改变一个人对其他角色群体的看法。无论我当时从事什么工作，我被赋予或承担的共同任务是成为不同群体之间的桥梁建设者。最明显的例子是在 CASE 工具时代的 Optima，当时我的职位是产品经理，但我的默认角色是将两个交战派系团结在一起——或者至少减少他们之间的敌意。在我担任业务系统协调员的工作中，我率先让炼油厂团队找到共同点。我的咨询工作总是需要将团队凝聚在一起。我最喜欢的杰里·温伯格名言之一是他的咨询第二定律：“无论问题是什么，它都是人的问题”（Weinberg，1985 年，第 5 页）。

Put a software developer into a sales representative’s shoes, or thrust a product manager into an executive role, and see how fast attitudes change. Having to function in another role can rapidly alter one’s opinion of other role groups. Whatever job I held at the time, the common task I was given or assumed was to be a bridge builder between different groups. The most visible example was at Optima in the CASE tool era, where my job title was product manager but my tacit role was to bring two warring factions together—or at least reduce the vitriol between them. In my business systems coordinator job, I spearheaded having refinery groups find common ground. My consulting work always involved bringing groups together. One of my favorite Jerry Weinberg quotes is his Second Law of Consulting: “No matter what the problem is, it’s a people problem” (Weinberg, 1985, p. 5).

在与任何客户打交道之前，我都会提醒自己这句话，因为我发现这句话是真的。这几乎总是人的问题。也许最好的建议还是来自杰里：“领导力是创造一种让人们获得权力的环境的过程”（Weinberg，1986 年，第 12 页）。

I reminded myself of this quote before any client engagement because I’ve found it to be true. It’s nearly always a people problem. Maybe the best advice comes, again, from Jerry: “Leadership is the process of creating an environment in which people become empowered” (Weinberg, 1986, p. 12).

考虑到 Jerry 的名言、敏捷宣言以及我自己的经历，我提出以下几点：

Thinking about Jerry’s quotes, the Agile Manifesto, and my own experiences, I offer the following:

根据我六十年的经验，我认为成功的根本原因是人及其互动，失败的根本原因也是人及其互动。

Based on six decades of experience, I think the root cause of success is people and their interactions, and the root cause of failure is also people and their interactions.

Tech@Core 鼓励企业中从上到下的每个人更好地了解我们生活的技术世界。软件方法、方法论和思维方式是将这些技术变为现实所必需的。但我们不能忘记，技术和软件开发的核心是人及其互动。

Tech@Core encourages everyone in an enterprise, from top to bottom, to better understand the technological world we live in. Software methods, methodologies, and mindsets are required to bring those technologies to life. But we can’t forget that at the core of technology and software development are people and their interactions.

我最喜欢的冒险故事不是埃德蒙·希拉里爵士首次攀登珠穆朗玛峰，也不是意大利队首次登顶乔戈里峰（世界第二高峰），而是鲜为人知的首次攀登 8000 米高峰——1950 年安纳普尔纳峰。莫里斯·赫尔佐格 (Maurice Herzog) (1952) 讲述的那次攀登故事引人入胜，从在未知的荒野中徘徊数周试图找到这座山峰，到艰苦地建立更高的营地，到寻找一条路线，到几乎爬到顶峰，然后在危险的下山过程中发生一系列事故，差点以死亡结束了这次探险。手指和脚趾因冻伤而被切除。

MY FAVORITE ADVENTURE story isn’t about Sir Edmond Hillary’s first climb of Mount Everest or the Italian team that was first to summit K2 (the world’s second highest mountain), but rather a less well-known first scaling of an 8,000-meter peak—Annapurna in 1950. Maurice Herzog’s (1952) story of that ascent is riveting, from weeks wandering around uncharted wilderness trying to find the mountain, to the backbreaking work of setting up successively higher camps, to figuring a route to follow, to the near crawl to the summit, and then a series of mishaps on the dangerous descent, which nearly ended the expedition in death. Fingers and toes were removed due to frostbite.

虽然我从未尝试过攀登任何像安纳普尔纳峰这样困难的山峰，但阅读赫尔佐格的书激励了我去攀登山峰。虽然不会危及生命，但攀登软件开发山峰也是一种挑战。这些软件挑战是由不同的冒险家完成的，从 Structured 时代的 Tom DeMarco、Larry Constantine 和 Ken Orr，到 Kent Beck、Alistair Cockburn、Martin Fowler 和敏捷时代的 Ken Schwaber——以及那些敢于尝试前沿、偶尔是前沿的想法的经理和高管。

Although I’ve never attempted a climb anywhere remotely as difficult as Annapurna, reading Herzog’s book inspired me to climb mountains. Although not life-threatening, ascending software development mountains offered a challenge as well. Those software challenges were climbed by a different set of adventurers, from Tom DeMarco, Larry Constantine, and Ken Orr in the Structured era to Kent Beck, Alistair Cockburn, Martin Fowler, and Ken Schwaber in the Agile era—and by the managers and executives who took a chance on their leading-edge, and occasionally bleeding-edge, ideas.

写这本书是我最近的一次冒险。这是一个挑战，就像我第一次在冬天在落基山国家公园攀冰一样——不知所措，不知道会发生什么。在某个时候，我挣扎于各种叙事之间的相互作用，与我的教女艾米·欧文 (Amy Irvine) 讨论了我的挫败感，她是一名作家（欧文，2018 年），也是南新罕布什尔大学创意写作美术硕士项目的教员。当艾米将她的环境文章描述为编织的叙事时，我立刻意识到我找到了一个可以运用的组织原则。

Writing this book has been my recent adventure. It has been a challenge, comparable to my first ice climb in winter in Rocky Mountains National Park—striking out, not knowing what to expect. At some point, struggling with the interplay of the various narratives, I discussed my frustration with my goddaughter, Amy Irvine, an author (Irvine, 2018) and a faculty fellow at Southern New Hampshire University’s Master of Fine Arts program for creative writing. As Amy described her environmental articles as braided narratives, I realized instantly that I had found an organizing principle to work with.

因此，在反复尝试和众多人的大力帮助下，这本书诞生了。当我第一次向同事提出写这本书的想法时，我开玩笑说：“这要么是我有过的最好的想法，要么是最糟糕的想法。”你觉得是哪一个？

So, with fits and starts and tremendous help from a host of others, this book emerged. When I first proposed this book idea to colleagues, I quipped, “This is either the best idea I’ve ever had, or the worst.” Which do you think it is?

为什么要写这本书？

Why write this book?

我写这本书的初衷是希望通过向读者介绍我、我的动机、我的观点、我的个性以及塑造我职业生涯的驱动力，让软件开发的历史变得更容易理解，并且我希望，让读者更愉快。

I wrote this book assuming that telling readers about me, my motivations, my perspective, my personality, and the drivers that shaped my career might make the history of software development more understandable and, I hope, more enjoyable.

除了家庭之外，寻求冒险——无论是事业还是个人——一直是我生活的重心。在这本书中，我表达了一些关于我是谁以及我工作背后的总体目的。

After family, seeking adventures—career and personal—has been central to my life. Over the course of this book, I’ve conveyed a bit about who I am and the overall purpose behind my work.

重新回顾我写这本书的目标：

To revisit my goals for this book:

• 记录软件方法、方法论和思维方式的演变和革命。

• Document the evolution and revolution of software methods, methodologies, and mindsets.

• 缅怀并纪念软件开发的先驱者。

• Remember and honor the pioneers of software development.

• 汲取过去的教训，为未来做好准备。

• Prepare for the future, by learning from the past.

• 为我这一代人提供一个回忆过去经历的事件的媒介。

• Give my generation a vehicle to reminisce about events we lived through.

• 让年轻一代了解他们可能错过的事件。

• Give younger generations a peek into events they may have missed.

此外，我希望我的孙子们能了解我，了解我的职业生涯。我想给他们的不仅仅是家谱，不仅仅是“叔叔马克斯于 1921 年与格雷塔结婚”或“我从 1965 年到 1968 年在 ABC 公司担任软件开发人员”。当我为家人写回忆录时，我意识到我的职业生涯与许多六十年来，软件和技术发生了翻天覆地的变化，而我也参与了这段历史。也许其他人也会感兴趣。

Additionally, I wanted my grandkids to know something about me, to understand something about my career. I wanted to give them more than a genealogy, something beyond “great uncle Max married Greta in 1921” or “I worked for ABC company as a software developer from 1965 to 1968.” As I worked on a memoir for my family, I realized my career paralleled vast changes in software and technology over six decades and I had played a part in that history. Maybe others would be interested.

为什么有这么多关于中世纪或加州淘金热的书？因为历史学家提供了一个独特的视角来观察过去的事实。事实是拿破仑·波拿巴是一位法国军事和政治领袖，在法国大革命期间声名鹊起。但为什么有这么多历史学家写过他？因为每个历史学家都有特定的视角或观点来提供给读者。当我写下我在软件开发时代的历程时，我希望我的故事能提供一个有价值的视角。

Why are so many books written about the Middle Ages or the California Gold Rush? Because historians provide a unique lens through which to view the facts of the past. The facts are that Napoléon Bonaparte was a French military and political leader who rose to prominence during the French Revolution. But why have so many historians written about him? Because each historian has a particular lens or perspective to offer the reader. As I wrote about my journey through the eras of software development, I hope my stories offered a valuable perspective.

在我职业生涯的六十年中，发生了许多变化，其中变化最大的莫过于多样性、公平和包容性 (DEI) 问题。20 世纪 60 年代——当时我还在读高中、大学和职业生涯的早期——为争取边缘群体的公民权利而展开了激烈的斗争。到 2022 年，取得了一些进展，例如同性婚姻合法化和女性在劳动力中的作用扩大，但正如“黑人的命也是命”和“我也是”运动所证明的那样，还有很长的路要走。1962 年，当我就读于一所农业与工程大学时，学生群体中 95% 是男性，5% 是女性。如今，这所大学的男性占 51%，女性占 49%，并且拥有全面的 DEI 课程。

Much has changed in the six decades of my career, nowhere more than in relation to issues around diversity, equity, and inclusion (DEI). In the 1960s—while I was in high school, college, and early career—there were turbulent battles for marginalized groups’ civil rights. By 2022, there were gains, such as legalization of same-sex marriage and expansion of women’s roles in the workforce, but as the “Black Lives Matter” and “Me Too” movements proved, there is a still a long way to go. In 1962, when I enrolled at an agricultural and engineering university, the student body was 95% male and 5% female. Today, that university is 51% male and 49% female and has a comprehensive DEI program.

如果历史可以帮助我们为未来做好准备，那么从狂野西部到敏捷，或者说敏捷性总体上，在为我们准备一个更具包容性的未来方面可以发挥什么作用呢？首先，我希望敏捷运动对协作、自组织、授权团队的融入，以及对富有同理心的管理风格的强调，能够在推进 DEI 目标方面发挥积极作用。传统上代表性不足的群体正在将他们的声音和行动带入敏捷的文化变革实践中。与任何转型一样，需要具体行动、系统方法和思维方式的改变。与任何转型一样，思维方式是最重要的。

If history helps us prepare for the future, then what role can Wild West to Agile, or agility in general, play in preparing us for a more inclusive future? For one thing, I hope the agile movement’s incorporation of collaborative, self-organizing, empowered teams and its emphasis on an empathetic management style has played an active part in furthering DEI goals. Traditionally underrepresented groups are bringing their voices and actions to the cultural-change practices of agility. As with any transformation, specific actions, systemic approaches, and changes in mindset are needed. As with any transformation, mindset is the most important.

多样性对组织有很多好处，例如，“66% 的情况下，团队做出的决策比个人更好。年龄 + 性别 + 地域 — 多元化团队做出的决策在 87% 的情况下更佳。” ¹

Diversity benefits organizations in many ways, for example, “Teams make better decisions than individuals do 66 percent of the time. Age + gender + geographic—diverse teams make better decisions 87 percent of the time.”¹

1. Cloverpop 的研究，“通过包容性决策解决多样性问题”，www.cloverpop.com。

1. Study by Cloverpop, “Hacking Diversity with Inclusive Decision Making,” www.cloverpop.com.

2000 年代初，一位ComputerWorld专栏作家因支持同性恋权利问题而遭到读者的猛烈批评；这位读者认为该专栏不适合企业界。我加入 Thoughtworks 的原因之一是我职业生涯最后十年最难忘的一件事是公司致力于各种形式的多样性。从 1990 年代创业开始，创始人兼长期首席执行官 Roy Singham 就将社会正义问题融入了 Thoughtworks 的结构和 DNA 中。这种根深蒂固的声音仍然响亮。2022 年，56% 的高管职位由女性和代表性不足的性别群体 (WUGM) 担任。2、3^{不再有任何场合——无论}是企业、政府、宗教还是非营利组织——可以对多样性问题保持沉默。

In the early 2000s, a ComputerWorld columnist was lambasted by a reader for supporting a gay rights issue; the reader argued the column had no place in the corporate world. One of the reasons I joined Thoughtworks for the last decade of my career was the company’s commitment to diversity in all its forms. From its 1990s start-up, Roy Singham, founder and longtime CEO, incorporated social justice issues into the fabric, the DNA, of Thoughtworks. That embedded voice still rings loud. In 2022, 56% of executive-level positions are held by women and underrepresented gender groups (WUGM).^{2, 3} There is no longer any venue—corporate, governmental, religious, or nonprofit—where silence about diversity issues can be justified.

2 . www.thoughtworks.com/about-us/diversity-and-inclusion/our-people

2. www.thoughtworks.com/about-us/diversity-and-inclusion/our-people

3.许多其他公司也有类似的 DEI 成功案例。

3. Many other companies have similar DEI success stories.

作为一个享有特权的人，我撰写了一篇关于一个在包容多样性方面进展缓慢的行业的报道，我支持那些呼吁改变观念的人。我的目标是让更多人意识到并理解 DEI，并成为转型过程中的盟友。

As a person of privilege, writing about an industry that has been slow to incorporate diversity, I add my voice to those calling for a mindset change. My goal is to move the bar closer to wider awareness and understanding of DEI and be an ally in the transformation process.

目的

Purpose

在狂野的西部时代，职业规划很简单——被一家大公司聘用，工作到 65 岁，然后退休。对于那些选择其他路线的人来说，这更棘手。像我一样，那些寻找其他职业的人从一丝不苟的规划者到随机的跳槽者。随着变化的速度开始颠覆经济的主要部分，即使是那些拥有一站式计划的人也被归入一个随机类别，他们往往准备不足。我花了数年时间才阐明我自己的职业指南是目的，而不是计划。我早期设想的任何计划都无法经受现实的考验。我需要的不是计划，而是目的（公司开始利用这个想法）。

In the Wild West era, career planning was simple—be hired by a big company, work until you were 65 years old, retire. It was trickier for those who chose another route. Like me, those who searched for other niches were on a spectrum from meticulous planners to random job hoppers. As the rate of change began upending major segments of the economy, even those people with a one-stop plan were thrown into a random category, for which they were often ill prepared. It took me years to articulate my own career guide was purpose, not plan. Any plan I could have conceived early on would not have withstood reality. What I needed was not a plan, but rather a purpose (an idea that companies are beginning to utilize).

我希望我能说这些年来我一直被一个清晰的目标所驱动，从一开始就全神贯注，但我不能。我的目标，我的“为什么”一直在断断续续地发展，直到最后一块拼图才拼凑完整。现在回首过去几十年，这些驱动力或目标已经出现并发展，但核心思想却一直存在。我在前面的章节中提到过这个目标的各个方面，以下四个反映了我目前的想法：

I wish I could say a well-articulated purpose drove me all these years, that I was laser focused from the start, but I can’t. My purpose, my why, has evolved in fits and starts and scrambles, with the last piece just falling in place. As I now look back over the decades, these drivers or purposes have emerged and evolved, but the core ideas have remained. I’ve mentioned aspects of this purpose in earlier chapters, and these four reflect my current thinking:

• 提供有价值的软件

• Deliver valuable software

• 促进开明的领导

• Promote enlightened leadership

• 发展数字化企业

• Grow digital enterprises

• 分享我的故事

• Share my stories

或者更详细地讲：

Or, in a little greater detail:

这个目的陈述并不像我希望的那样简洁，但它传达了对我来说很重要的概念 - 提供客户价值；创造新的方法、方法论和思维方式；确保高技术质量的软件能够持续而不是离散地交付。

This purpose statement isn’t as pithy as I would like, but it conveys concepts important to me—delivering customer value; creating new methods, methodologies, and mindsets; ensuring high technical quality software that has the ability to deliver continuously rather than discretely.

有些人的目标是让世界变得更美好。这比我想要解决的问题要多得多。我想让工作场所变得更好，但这也有点牵强。我希望我的目标是有抱负的、可行的，所以我会把范围进一步缩小——只限于我合作过的客户的工作场所以及我的书籍、文章和博客的读者。

Some people’s purpose is to make the world a better place. That’s more than I want to tackle. I’d like to make workplaces better, but that’s a stretch as well. I want my purposes to be aspirational and doable, so I will narrow the scope even further—to the workplaces of clients I’ve worked with and the readers of my books, articles, and blogs.

我职业生涯的最后十多年主要致力于与高级经理和 Thoughtworks 同事合作进行企业数字化转型——使用敏捷软件开发实施作为跳板，整合敏捷性（思维方式）和技术（方法）。

The last 10-plus years of my career were predominantly spent working with senior managers and Thoughtworks colleagues on enterprise digital transformations—using agile software development implementations as a springboard to integrate agility (mindset) and technology (methods).

最近，我在反思自己的写作时添加了最后一个目的。在我的每一本书中，我都添加了一个细节，希望这能让故事更吸引人、更令人满意——从类比到登山，再到采访与名人、客户故事、使用非正式的个人声音。这本书包含了所有这些内容，还有一个新的内容——个人经历故事。这是一个挑战。

I added this last purpose recently as I reflected on my writing. In each of my books, I’ve added a wrinkle that I hope made the narrative more appealing and satisfying—from analogies to mountain climbing, to interviews with luminaries, to client stories, to using an informal personal voice. This book contains all of these wrinkles plus a big new one—personal experience stories. It has been a stretch and a challenge.

通过讲述我的个人故事、我的职业目标以及我写这本书的原因，我希望鼓励你们讲述自己的故事。气候变化、地缘政治冲突、流行病健康挑战、技术创新及其伴随的社会正义问题的冲击将持续下去。我们将需要新一代深思熟虑、积极参与的技术专家和领导者，以适应这个动荡的未来。这种领导力不会出现在对最新和最伟大的技术或管理理论的解释中。它需要个人风格、个人旅程和个人故事。在写这本书的过程中，我不断面临着将技术与我的个人故事交织在一起的挑战。

By offering my personal stories, my career purposes, and my reasons for writing this book, I hope to encourage you to tell your own stories. The onslaught of climate change, geopolitical conflict, pandemic health challenges, technology innovation, and their accompanying social justice issues will continue. We are going to need a new generation of thoughtful, engaged technologists and leaders who can adapt to this volatile future. This leadership won’t be found in an explanation of the latest and greatest technology or management theory. It needs a personal touch, personal journeys, and personal stories. Writing this book, I was constantly faced with the challenge of braiding technology together with my personal stories.

许多同事鼓励我强调个人，并鼓励我克服自己的不情愿——他们是对的。我在此鼓励你们讲述你们的个人故事。我不只是想知道你的想法，我想知道你是谁。我重申第 9 章中的观点：“我认为成功的根本原因是人及其互动。”如果这是真的，我相信这是真的，那么我们彼此了解得越多，我们的互动就会越好，最终我们就能为世界带来更多的成功和幸福。

Many colleagues challenged me to stress the personal, and pushed me through my reluctance—and they were right. I hereby challenge you to tell your personal stories. I don’t just want to know what you think, I want to know who you are. I reiterate the idea from Chapter 9: “I think the root cause of success is people and their interactions.” If this is true, and I believe it is, the better we know each other, the better our interactions can be, and ultimately the more success and well-being we can bring to the world.